用 go-mysql-elasticsearch 实现数据同步的本地化实践。

对于一个服务端开发来说 MYSQL 可能是他使用最熟悉的数据库工具，然而，大部分的Java工程师对MySQL的了解和掌握程度，大致就停留在这么一个阶段:它可以建库、建表、建索引，然后就是对里面的数据进行增删改查，语句性能有点差？没关系，在表里建几个索引或者调整一下查询逻辑就可以了，一条sql，MYSQL是如何处理的，为我们做了什么，完全是个黑盒。本文主要通过sql执行的过程打破这样一个黑盒的认知，来了解MYSQL的逻辑架构。

分享有关悬挂事物的相关知识及一例生产环境中的关于悬挂事务的案例。

MySQL等值查询，可能并不是你想的那么简单，还跟校对规则有对，具体细节且听本文娓娓道来。

Uber uses MySQL as the underlying database engine for Schemaless and Docstore, our distributed databases. By default, MySQL uses the most popular InnoDB engine, a B+Tree structure for data storage. MyRocks is a MySQL storage engine that integrates with RocksDB, an open source project. The RocksDB store is based on the log-structured merge-tree (or LSM tree) and is optimized for fast storage and combines outstanding space and write efficiency with acceptable read performance.

The Uber Storage Platform team has migrated all Schemaless instances and some Docstore instances to MyRocks since 2019. In this post, we are going to talk about the journey of our migration to MyRocks.

innodb支持空间索引，但很少有关于innodb关于空间索引的实现的介绍文章，本篇文章主要目的是介绍innodb关于空间索引的源码介绍，知其所以然。空间索引本质上是二级索引中的一种，基于R树实现。

innodb索引主要是基于B+树实现，B+树是一棵平衡树，是把一维直线分为若干段线段，当我们查找满足某个要求的点的时候，只要去查找它所属的线段即可。这种思想其实就是先找一个大的空间，再逐步缩小所要查找的空间，最终在一个自己设定的最小不可分空间内找出满足要求的解。B+树是解决低纬度数据（通常一维，也就是一个数据维度上进行比较），R树很好的解决了高维空间搜索问题。它把B树的思想很好的扩展到了多维空间，采用了B树分割空间的思想（如果B树在一维的线段进行分割，R树就是在二维甚至多维度的空间），并在添加、删除操作时采用合并、分解结点的方法，保证树的平衡性。因此，R树就是一棵用来存储高维数据的平衡树。

为了保障数据安全，MySQL 在 5.7 版本就支持了 InnoDB 表空间加密，之前写了一篇月报介绍过，参考InnoDB 表空间加密。文章开头也提到过，MariaDB 除了对表空间加密，也可以对 redo log 和 binlog 加密，本质上 redo log 和 binlog 中也保存着明文的数据，如果文件被拖走数据也有丢失的风险，因此在 MySQL 8.0 中也支持两种日志的加密，本文介绍 Binlog 的加密方式，建议先了解一下表空间加密，更容易理解。

InnoDB 表空间加密是在引擎内部数据页级别的加密手段，在数据页写入文件系统时加密，从文件读到内存中时解密，目前广泛使用的是 YaSSL/OpenSSL 提供的 AES 加密算法，加密前后数据页大小不变，因此也称为透明加密。表空间加密相对于文件系统加密更加灵活，用户可以控制加密重要的表，防止被拖库导致的数据丢失。MySQL 官方在 5.7.11 中发布了表空间加密功能，Aliyun RDS 差不多在同时支持了 RDS MySQL 版的表空间加密，通过了“等保三级” 的认证，随后 MariaDB 在 10.1 支持了功能增强版的“表空间加密”，除了表空间，还可以对 Redo log 和 Binlog 进行加密，参考这篇详细介绍。本文将详细介绍官方的实现方式。

InnoDB会将事务执行过程拆分为若干个Mini Transaction（mtr），每个mtr包含一系列如加锁，写数据，写redo，放锁等操作。

MySQL Online DDL 功能从 5.6 版本开始正式引入，发展到现在的 8.0 版本，经历了多次的调整和完善。本文主要就 Online DDL 的发展过程，以及各版本的区别进行总结。其实早在 MySQL 5.5 版本中就加入了 INPLACE DDL 方式，但是因为实现的问题，依然会阻塞 INSERT、UPDATE、DELETE 操作，这也是 MySQL 早期版本长期被吐槽的原因之一。

在 MySQL 5.6 中，官方开始支持更多的 ALTER TABLE 类型操作来避免数据拷贝，同时支持了在线上 DDL 的过程中不阻塞 DML 操作，真正意义上的实现了 Online DDL。然而并不是所有的 DDL 操作都支持在线操作，后面会附上 MySQL 官方文档对于 DDL 操作的总结。到了 MySQL 5.7，在 5.6 的基础上又增加了一些新的特性，比如：增加了重命名索引支持，支持了数值类型长度的增大和减小，支持了 VARCHAR 类型的在线增大等。但是基本的实现逻辑和限制条件相比 5.6 并没有大的变化。MySQL 8.0 对 DDL 的实现重新进行了设计，其中一个最大的改进是 DDL 操作支持了原子特性。另外，Online DDL 的 ALGORITHM 参数增加了一个新的选项：INSTANT，只需修改数据字典中的元数据，无需拷贝数据也无需重建表，同样也无需加排他 MDL 锁，原表数据也不受影响。整个 DDL 过程几乎是瞬间完成的，也不会阻塞 DML。

本文将结合MySQL分区表功能重点介绍一致性哈希算法以及其他一些哈希算法的特性和在分区表中的使用。

你知道为何MySQL binlog时间有时会出现乱序情况吗？

分析页面I/O数与索引高度的关系，以及索引高度的查看方法。

在携程国际化战略背景下，海外业务将成为新的发力点，为了保证用户高品质的服务体验，底层数据势必需要就近服务业务应用。一套标准且普适的数据复制解决方案能够提升业务决策效率，助力业务更快地触达目标用户。

DRC (Data Replicate Center) 作为携程内部数据库上云标准解决方案，支撑了包括但不限于即时通讯、用户账号、IBU在内的核心基础服务和国际业务顺利上云。

max_allowed_packet 表示 MySQL Server 或者客户端接收的 packet 的最大大小，packet 即数据包，MySQL Server 和客户端上都有这个限制。

MySQL数据库读写分离，是提高服务质量的常用手段之一，而对于技术方案，有很多成熟开源框架或方案，例如：sharding-jdbc、spring中的AbstractRoutingDatasource、MySQL-Router等，而mysql-jdbc中的ReplicationConnection亦可支持。本文暂不对读写分离的技术选型做过多的分析，只是探索在使用druid作为数据源、结合ReplicationConnection做读写分离时，连接失效的原因，并找到一个简单有效的解决方案。