分库分表带来的问题整理

1.在分库分表后，每张表的自增ID只在本表范围内唯一，但无法保证全局唯一。

例如：

• 订单表_1 的主键从 1 开始，订单表_2 的主键也从 1 开始。
  

• 在需要全局唯一 ID 的场景（如订单号、用户 ID）中会发生冲突。

解决方案

1）使用分布式 ID 生成器

推荐工具：

• Snowflake：Twitter 开源的分布式 ID 算法。

• 百度 UidGenerator：基于 Snowflake 的改进版。

• Leaf：美团开源，号段模式和 Snowflake 双支持。

2）数据库号段分配

原理：维护一个独立的 global_id 表，分库按步长分配 ID：

• 库 1：ID 步长为 3，从 1 开始（1, 4, 7...）。

• 库 2：ID 步长为 3，从 2 开始（2, 5, 8...）。

• 库 3：ID 步长为 3，从 3开始（3, 6, 9...）。

2.分库分表后，聚合查询（如总数统计、分页查询）需要跨多个分片表执行，增加了查询复杂度。

例如：

• 查询所有订单总数，需要跨 10 个订单表聚合。

• 按创建时间分页查询所有订单。

解决方案

1）使用中间件（推荐）

• ShardingSphere 或 MyCAT：支持 SQL 分片执行和结果合并。

• 优点：业务代码无需修改，中间件完成分库分表逻辑。

2）手动分片查询

• 按分片逐一查询数据，在业务层合并结果。

3.分布式事务（如订单表在库 A，库存表在库 B）无法使用单库事务，导致可能会出现数据的一致性问题。

解决方案

1）TCC方案

2）本地消息表+MQ一部消费

2）RocketMQ支持分布式事务

4.分片键选择不当可能导致数据倾斜（热点问题）或查询路由效率低。

解决方案

1）分片键设计原则

• 数据分布均匀：避免热点问题。

• 常用查询字段：尽量选高频查询字段。

2）路由表

• 维护全局路由表，映射分片键到分表。

5.数据迁移问题，扩容（如从 4 个分片扩展到 8 个分片）时，旧数据需要迁移到新分片，迁移复杂且可能影响线上服务。

解决方案

1）双写策略

• 数据迁移期间，旧表和新表同时写入。

• 待迁移完成后，切换到新表。

2）增量同步

• 使用 Canal 监听 MySQL Binlog，将数据迁移到新分片。

6.分页查询需要从多个分片表合并数据，再统一分页，逻辑复杂度增加。

解决方案

1）各分片分页后合并：先按分片分页查询，业务层合并排序后分页。

2）中间件支持分页：如 ShardingSphere。

7.分库分表后，运维难度增加：

• 数据库实例多，监控和备份复杂。

• 故障排查需要跨多个库。

解决方案

2）自动化运维平台：如阿里云 DMS。

2）监控工具：使用 Prometheus + Grafana 实现分片监控。