数据库主从架构、读写分离

Question

如果在 MySQL 读写都有瓶颈，那⾸先看下⽬前 MySQL 的架构是怎么样的。如果是单库的，那是不是可以考虑升级⾄主从架构，实现读写分离。简单理 解就是：主库接收写请求，从库接收读请求。从库的数据由主库发送的 binlog 进⽽更新，实现主从数据⼀致（在⼀般场景下，主从的数据是通过异步来保证最 终⼀致性的）。

分库分表

如果在主从架构下，读写仍存在瓶颈，那就要考虑是否要分库分表。我这⾥讲的分库分表的含义是：在原来的某个库的某个表进⽽拆分。⽐如，现在我有⼀张 业务订单表，这张订单表在订单库中，假定这张业务订单表已经有 1 亿数据量了，现在我要分库分表，那就会将这张表的数据分⾄多个订单库以及多张表中。

分库分表的最明显的好处就是把请求进⾏均摊（本来单个库单个表有⼀亿的数据，那假设我分开 8 个库，那每个库 1200+W 的数据量，每个库下分 8 张表，那每张表就 150W 的数据量）。

按照我们这边的经验，⼀般来说是按照 userId 的（因为按照⽤户的维度查询⽐较多），如果要按照其他的维度进⾏查询，那还是参照上⾯的的思路（以空间换时间）。

分库分表后的 ID 有借助 MySQL⾃增的，有借助 Redis⾃增的，有基于「雪花算法」⾃增的。具体使⽤哪种⽅式，那就看公司的技术栈了，⼀般使⽤ Redis 和基于「雪花算法」实现⽤得⽐较多。⾄于为什么强调⾃增还是跟索引是有序有关，一直自增这样插入的时候不会频繁变动 B+树的叶子节点所链接的指 针。

迁移过程

我们⼀般采取「双写」的⽅式来进⾏迁移，⼤致步骤就是：

1. 增量的消息各⾃往新表和旧表写⼀份
2. 将旧表的数据迁移⾄新库
3. 迟早新表的数据都会追得上旧表（在某个节点上数据是同步的）
4. 校验新表和⽼表的数据是否正常（主要看能不能对得上）
5. 开启双读（⼀部分流量⾛新表，⼀部分流量⾛⽼表），相当于灰度上线的过程
6. 读流量全部切新表，停⽌⽼表的写⼊
7. 提前准备回滚机制，临时切换失败能恢复正常业务以及有修数据的相关程序。

总结

• 数据库表存在⼀定数据量，就需要有对应的索引
• 发现慢查询时，检查是否⾛对索引，是否能⽤更好的索引进⾏优化查询速度，查看使⽤索引的姿势有没有问题
• 当索引解决不了慢查询时，⼀般由于业务表的数据量太⼤导致，利⽤空间换时间的思想
• 当读写性能均遇到瓶颈时，先考虑能否升级数据库架构即可解决问题，若不能则需要考虑分库分表
• 分库分表虽然能解决掉读写瓶颈，但同时会带来各种问题，需要提前调研解决⽅案和踩坑