我爱娃哈哈的专栏

MySQL 数据库可以很好地支撑海量的 OLTP（Online Transaction Processing）的系统，但是对于海量的互联网业务来说，数据量是非常巨大的。假设一天 10 亿笔交易，每笔交易至少需要有一条记录，用于记录该笔交易，这就是通常所谓的流水数据。再假设一笔流水占用 1K 存储空间，那么每日流水占用存储空间 1000G，365 天就需要占用 365T 的存储空间。

引起 MySQL 数据库性能抖动的原因有很多，比如大事务、定时批量查询等，而这些原因我们一般都会注意到。但是，有一个引起性能抖动的原因却经常被我们忽视，那就是在生产环境删除无用的大表，即 DROP TABLE。

前面介绍了很多关于分布式数据库的一些知识点，但是，分布式数据库还有一个很令人头疼的问题，那就是分布式事务。本篇文章，我们就来看一下，如何在海量的互联网业务中实现分布式事务。

访问分布式数据库有两种模式：业务直接根据分库分表访问 MySQL 数据库节点；根据中间件访问。

前面我们了解了分布式数据库的架构，知道各类分布式数据库都离不开计算层、存储层、元数据层这三层关系。另外，很重要的一点是，了解了分布式数据库是把数据打散存储在一个个分片中。在基于MySQL 的分布式数据库架构中，分片就存在于 MySQL 实例中。本篇文章，我们就来了解一下，如何正确的把数据分片，充分发挥分布式数据库架构的优势。

Wiki 官方对分布式数据库的定义为：从定义来看，分布式数据库是一种把数据分散存储在不同物理位置的数据库。对比之前的数据库，数据都是存放在一个实例对应的物理存储上，而在分布式数据库中，数据将存放在不同的数据库实例上。从图中可以看到，在分布式数据库下，分布式数据库本身分为计算层、元数据层和存储层：计算层就是之前单机数据库中的 SQL 层，用来对数据访问进行权限检查、路由访问，以及对计算结果等操作。元数据层记录了分布式数据库集群下有多少个存储节点，对应 IP、端口等元数据信息是多少。

但设置 AFTER_SYNC 无损半同步的好处是，虽然事务 101 在原主机已经提交，但是在从机没有收到并返回 ACK 前，这个事务对用户是不可见的，所以，用户感受不到事务已经提交了。可以看到当主从切换完成后，新的 MySQL 开始写入新的事务102，如果这时老的主服务器从宕机中恢复，则这时事务 101 不会同步到新主服务器，导致主从数据不一致。从图中可以看到，我们加入两个异步复制的节点，用于业务实现读写分离，另外再从机房 3 的备机中，引入一个异步复制的延迟备机，用于做数据误删除操作的恢复。

此外，这里也用到了 MySQL 复制中的部分复制技术，即左上角的主服务器仅将 DB1 中的数据同步到右上角的服务器。“基于业务层的数据库高可用架构”中，虽然通过跳单设计，可以实现写入业务的高可用实现。这样的话，当写入服务器编号 1 时失败了，业务层会把订单的主键修改为服务器编号 2，这样就实现了业务层的高可用，电商中的这种订单号生成方式也称为“跳单”。上图中，将不同编号的订单根据不同的数据库进行存放，比如服务器编号为 1 的订单存放在数据库 DB1 中，服务器编号为 2 的订单存放在数据库 DB2 中。

假设有个 DELETE 删除操作，删除当月数据，由于数据量可能有 1 亿条记录，可能会产生 100G 的二进制日志，则这条 SQL 在提交时需要等待 100G 的二进制日志写入磁盘，如果二进制日志磁盘每秒写入速度为 100M/秒，至少要等待 1000 秒才能完成这个事务的提交。大家可能会发现，自己的主从复制会存在主从数据延迟的问题，甚至会导致读写分离，架构设计在业务层出现较为严重的问题，比如迟迟无法读取到主库已经插入的数据。当然，若是一些报表类的查询，只要不影响最终结果，业务是能够容忍一些延迟的。

在半同步复制中，有损半同步复制是 MySQL 5.7 版本前的半同步复制机制，这种半同步复制在Master 发生宕机时，Slave 会丢失最后一批提交的数据，若这时 Slave 提升（Failover）为Master，可能会发生已经提交的事情不见了，发生了回滚的情况。如果业务对于数据一致性要求不高，当发生故障时，能容忍数据的丢失，甚至大量的丢失，推荐用异步复制，这样性能最好（比如像微博这样的业务，虽然它对性能的要求极高，但对于数据丢失，通常可以容忍）。数据库复制本质上就是数据同步。

3.分区表是将物理表结构相同的表通过分区函数组成逻辑大表，MySQL支持多种分区函数类型。分区表设计时，主键必须包含分区列，且唯一索引需考虑分区列以实现全局唯一。分区表主要用于数据管理，而非性能提升，查询条件应包含分区字段以避免扫描所有分区。以电商订单表为例，按年创建分区表可方便数据删除和管理。

2.MySQL8.0前版本对子查询优化有限，但新版本中优化大幅提升，推荐使用。子查询逻辑清晰，符合人类思维，但优化器需将其转换为最优JOIN连接。IN和EXISTS性能差异需关注执行计划。依赖子查询可能慢，需警惕并手动优化。

过滤出的数据少，那么这条 SQL 语句会先使用表 R 上列 y 上的索引，筛选出数据，然后再使用表 S 上列 x 的索引进行关联，最后再通过 WHERE S.z =?由于驱动表的数据是固定 30 条，因此不论表 orders、lineitem、part 的数据量有多大，哪怕是百亿条记录，由于都是通过主键进行关联，上述 SQL 的执行速度几乎不变。如果 OLTP 业务的 JOIN 带有 WHERE 过滤条件，并且是根据主键、索引进行过滤，那么驱动表只有一条或少量记录，这时进行 JOIN 的开销是非常小的。

MySQL 会根据成本计算得到最优的执行计划， 根据不同条件选择最优执行计划，而不是同一类型一成不变的执行过程，这才是优秀的优化器该有的样子。在关系型数据库中，B+ 树索引只是存储的一种数据结构，具体怎么使用，还要依赖数据库的优化器，优化器决定了具体某一索引的选择，也就是常说的执行计划。这些操作都在 Server 层完成。但是对于性别这样的字段，其值只有男和女两种，哪怕记录数再多，也只有两种值，这是低选择性的字段，因此无须在性别字段上创建索引。

本文介绍了组合索引的概念、设计实战及三大优势。通过案例展示了如何避免额外排序和回表，提升SQL查询性能。组合索引可覆盖多个查询条件，实现索引覆盖技术，提升查询效率。文章将持续更新，欢迎关注。

这时索引 idx_last_modify_date 的插入和 idx_register_date 类似，是比较顺序的，但不同的是，索引 idx_last_modify_date 会存在比较频繁的更新操作，比如用户消费导致余额修改、money 字段更新，这会导致二级索引的更新。索引是排序后的数据，而堆表中的数据是无序的，索引的叶子节点存放了数据在堆表中的地址，当堆表的数据发生改变，且位置发生了变更，所有索引中的地址都要更新，这非常影响性能，特别是对于 OLTP 业务。， 性能开销相对较大；

随着插入 B+ 树索引的记录变多，1个页（16K）无法存放这么多数据，所以会发生 B+ 树的分裂，B+ 树的高度变为 2，当 B+ 树的高度大于等于 2 时，根节点和中间节点存放的是索引键对，由（索引键、指针）组成。： B+ 树索引的维护代价非常小，叶子节点都是从左往右进行插入，比较典型的是自增 ID 的插入、时间的插入（若在自增 ID 上创建索引，时间列上创建索引，则 B+ 树插入通常是比较快的）。所以，上述的数据结构一般仅用于内存对象，基于磁盘的数据排序与存储，最有效的依然是 B+ 树索引。

MySQL支持多种访问方式，包括SQL和NoSQL。通过Memcached协议和XProtocol，可将MySQL打造成KV数据库或文档数据库，提升性能并满足复杂查询需求。MySQL在JSON支持、数据持久化、事务处理等方面优于原生Memcached，同时与MongoDB相比也具优势。

另一方面，所有页的读写操作都和非压缩页一样，没有开销，只有当这个页需要刷新到磁盘时，才会触发页压缩功能一次。数据库中的表是由一行行记录（rows）所组成，每行记录被存储在一个页中，在 MySQL 中，一个页的大小默认为 16K，一个个页又组成了每张表的表空间。这是因为不同于 COMPRESS 页压缩，TPC 压缩在内存中只有一个 16K 的解压缩后的页，对于缓冲池没有额外的存储开销。COMPRESS 页压缩就是将一个页压缩到指定大小，比如从16K压缩到8K，但是如果无法压缩到8K，则会产生两个8K的页。

相信在大学学习《数据库系统概论》时，肯定学习过关系数据库的设计规范，比如第一范式、第二范式、第三范式，BC 范式等，它们是《数据库系统概论》考试中重要的考点。所以，在进行表结构设计时，数据只需存放在一个地方，其他表要使用，通过主键关联存储即可。淘宝订单号的最后 6 位是用户 ID 相关信息，前 14 位是时间相关字段，这样能保证插入的自增性，又能同时保留业务的相关信息作为后期的分布式查询。范式设计是非常重要的理论，是通过数学集合概念来推导范式的过程，在理论上，要求表结构设计必须至少满足三范式的要求。

但是如果使用默认的操作系统时区，则每次通过时区计算时间时，要调用操作系统底层系统函数 __tz_convert()，而这个函数需要额外的加锁操作，以确保这时操作系统时区没有修改。除了 DATETIME，日期类型中还有一种 TIMESTAMP 的时间戳类型，其实际存储的内容为‘1970-01-01 00:00:00’到现在的毫秒数。在上面的表 User 中，列 register_date 表示注册时间，DEFAULT CURRENT_TIMESTAMP 表示记录插入时，若没有指定时间，默认就是当前时间。

这里有个情况要注意：在我们字符串存储的长度超过65536情况下，可以使用TEXT和BLOB来存储，这两个类型的最大存储长度为4G，TEXT和BOLB两者的区别在于BLOB没有字符集属性，属于二进制存储。在表结构的设计中，除了设计字段的数据类型外，我们还需要定义字符的字符集，不同的字符在不同的字符集编码下，对应着不同的二进制值。所以，在设计密码存储使用，还需要加盐（salt），每个公司的盐值都是不同的，因此计算出的值也是不同的。：表示动态盐，每次用户注册时业务产生不同的盐值，并存储在数据库中。

在软件开发中，作为后端，无可避免的需要熟练使用 MySQL 数据库进行数据存储和读取。对于信息系统而言，数据库的的地位不言而喻。那作为软件开发工程师，在使用 MySQL 过程中，又有哪些需要注意的呢？我们从实际开发来一点点的介绍。本篇文章，我们先来了解一下关于数据库数字类型的一些内容。我们在做表设计的时候，数字类型是常见的数据类型，用于存储数字相关的信息（整数型、浮点型、高精度型）。但是在不同的业务场景中，错误的使用数字类型，也会给系统带来很大的风险。