【MySQL】分库分表相关思考

1. 分库

随着业务的增长&＃xff0c;数据量的增加&＃xff0c;很多接口响应时间变得很长&＃xff0c;经常出现 Timeout&＃xff0c;而且通过升级 MySQL 实例配置已经无法解决问题了&＃xff0c;这时候就要分库。

垂直分库&＃xff1a;将不同的业务表分在不同的数据库中。

水平分库&＃xff1a;水平分库理论上切分起来是比较麻烦的&＃xff0c;它是将同一表数据拆分到不同数据库实例中。

2. 分表

分表的应用场景是单表数据量增长速度过快&＃xff0c;因为大表会影响查询性能&＃xff0c;DDL变更时间很长&＃xff0c;影响业务的可用性&＃xff0c;同时导致从库延迟很大。但是 MySQL 实例的负载并不高&＃xff0c;这时候只需要分表&＃xff0c;不需要分库。

垂直分表&＃xff1a;表中的字段太多&＃xff0c;需要切分字段&＃xff0c;一般将不常用的、 数据较大、长度较长的拆分到“扩展表“。

水平分表&＃xff1a;单表数据量太大&＃xff0c;按某种规则将单表数据拆分到多张表中。从理论上突破了单机数据量的瓶颈&＃xff0c;是分库分表的标准解决方案。

1. 取模分片

比如按主键ID取模&＃xff0c;将数据存储到不同的分片中。

• 优点&＃xff1a;数据存放比较均匀。
• 缺点&＃xff1a;扩容需要大量数据迁移。

2. 按范围分片

比如按日期范围进行分片。

• 优点&＃xff1a;扩容不需要迁移数据。
• 缺点&＃xff1a;数据存放不均匀&＃xff0c;容易产生数据倾斜。

3. 自定义分片

根据业务场景&＃xff0c;灵活定制分片策略

分片策略的选取需要考虑如何不迁移数据&＃xff0c;实现集群动态扩缩容&＃xff0c;同时又能保证数据分布相对均匀。可以采用整体按范围分片&＃xff0c;不同范围包含的分片数可以不同&＃xff0c;保证扩容时老数据不需要迁移。范围内&＃xff0c;按照取模分片&＃xff0c;让每个范围内的数据分布大致均匀。

以下只是建议&＃xff0c;不是绝对的要求。

• 预估数据量&＃xff1a;阿里建议3年内单表数据量大于500w或者单表数据文件大于2G&＃xff0c;就需要考虑分库分表。
• 数据增长趋势&＃xff1a;持续高速增长的数据需要尽早考虑分库分表&＃xff0c;并且要预留空间。
• 预估应用场景&＃xff1a;由于频繁变更分片键&＃xff0c;需要同时做数据迁移&＃xff0c;所以&＃xff0c;对于分片键变更频繁的数据&＃xff0c;不适合进行分库分表。
• 预估业务复杂度&＃xff1a;业务逻辑与分片逻辑绑定&＃xff0c;会给SQL执行带来很多限制。所以如果对数据的查询逻辑变化非常大&＃xff0c;通常不建议分库分表。

• 主键唯一性&＃xff1a;当数据被拆分到不同的表中后&＃xff0c;主键ID将可能不再满足唯一性。
• 分布式事务&＃xff1a;分库分表后&＃xff0c;就需要支持分布式事务了。数据库本身为我们提供了事务管理功能&＃xff0c;但是分库分表之后就不适用了。如果我们自己编程协调事务&＃xff0c;代码方面就又开始了麻烦。
• SQL路由&＃xff1a;一条数据插入SQL应该插入到哪个表&＃xff1f;这个问题与选取的分片策略息息相关。
• 结果归并&＃xff1a;由于查询的数据可能存在于多张表、多个库中&＃xff0c;所以需要对查询结果做归并处理。
• 动态扩容&＃xff1a;当数据又增长到一定阈值时&＃xff0c;就需要考虑扩容&＃xff0c;如何实现在不迁移或者少迁移数据的基础上实现动态扩容&＃xff1f;
• 联合查询困难&＃xff1a;联合查询不仅困难&＃xff0c;而且可以说是不可能&＃xff0c;因为两个相关联的表可能会分布在不同的数据库&＃xff0c;不同的服务器中。
• 多数据源&＃xff1a;分库分表之后可能会面临从多个数据库或多个子表中获取数据&＃xff0c;一般的解决思路有&＃xff1a;客户端适配和代理层适配。