MySQL分库分表

随着业务的发展和数据量的增长，单一数据库可能会面临存储容量、处理能力和IO性能的瓶颈。这些瓶颈可能导致数据库响应缓慢、查询效率低下，甚至系统崩溃。因此，当数据量或并发量达到一定阈值时，就需要考虑分库分表来提升性能和可伸缩性。

将原本存储在单个数据库上的数据拆分到多个数据库中（分库），把原来存储在单张表的数据拆分到多张数据表中，实现数据切分，从而提生数据库操作性能。分库分表的实现方式分为两种：垂直切分，水平切分。

1、水平分库

 概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。结果：

• 每个库的结构都一样；

• 每个库的数据都不一样，没有交集；

• 所有库的并集是全量数据；

场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。分析：库多了，io和cpu的压力自然可以成倍缓解。

数据迁移和扩容复杂，跨库事务难以保证一致性。

2、水平分表

概念：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
结果：

• 每个表的结构都一样；

• 每个表的数据都不一样，没有交集；

• 所有表的并集是全量数据；

场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。

跨表事务和join操作复杂，可能需要在应用层实现。

3、垂直分库

概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。结果：

• 每个库的结构都不一样；

• 每个库的数据也不一样，没有交集；

• 所有库的并集是全量数据；

场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

跨库事务处理和数据迁移困难。

4、垂直分表

 概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
结果：

• 每个表的结构都不一样；

• 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；

• 所有表的并集是全量数据；

场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

业务逻辑复杂，需要处理表之间的关联。

5、工具

1. 「shardingsphere（前身 sharding-jdbc）」

2. 「cobar」

3. 「Mycat」

4. 「Atlas」

5. 「TDDL（淘宝）」

6. 「vitess」

6、问题

分表分库是处理大规模数据和高并发场景的有效手段，但在实施过程中可能会遇到一系列问题：

1. 跨库join问题

- 在分库之后，原本可以通过SQL join操作完成的查询变得复杂，因为相关数据可能分布在不同的数据库实例中。解决这一问题通常需要避免跨库join，或者通过全局表、字段冗余、数据同步、系统层组装等策略来处理。

2. 分布式事务问题

- 分布式事务是分库分表后常见的问题，需要保证跨多个数据库实例的操作具有一致性。解决分布式事务问题通常需要采用两阶段提交、补偿事务等复杂的事务处理机制。

3. 数据迁移和扩容问题

- 分库分表后，数据迁移和扩容变得复杂。需要设计合理的数据迁移策略，如哈希取模、一致性哈希、按范围分片等，以减少数据迁移的影响。

4. 非分片键查询问题

- 当查询条件不是分片键时，需要先通过非分片键找到分片键，再进行数据查询。这可以通过建立非分片键与分片键之间的映射关系，或者通过将用户端数据库和运营端数据库分离来解决。

5. 数据一致性问题

- 在分库分表的环境中，保持数据的一致性是一个挑战。尤其是在分布式系统中，数据同步和一致性保证需要额外的机制和策略。

6. 全局主键避重问题

- 分库分表后，传统的自增主键可能不再适用，需要设计新的全局唯一ID生成策略，如UUID、数据库自增sequence、分布式ID生成器等。

7. 系统复杂度增加

- 分库分表增加了系统的复杂度，需要更多的中间件和工具来管理数据分片，同时应用层的逻辑也需要做相应的改造。

8. 性能瓶颈问题

- 虽然分库分表可以提高性能，但如果设计不当，可能会引入新的性能瓶颈，如数据热点问题、单点问题等。

9. 运维挑战

- 分库分表后，数据库的运维变得更加复杂，需要更多的监控和维护工作，以确保系统的稳定性和可用性。

在实施分库分表策略时，需要综合考虑这些问题，并根据具体的业务需求和系统架构采取相应的解决方案。