分表分库不是银弹，单表数据量达到千万级且出现明显性能瓶颈时才值得引入，核心难点在于分片键设计和数据迁移，而不是中间件选型。
什么时候该考虑分表分库，别被数据量吓住
很多团队一看到订单表几百G就慌,急着上分库分表，MySQL单表在千万级数据量、磁盘IO没有打满的情况下，配合合理的索引依然能跑得不错，分表分库带来的复杂度是实打实的，分布式事务、跨节点join、全局主键生成，每一个都能让你加班到深夜。
先看这几个信号再动手
- 单表数据量超过2000万行，且日常查询主要走索引，但响应时间从个位数毫秒涨到几百毫秒
- 写入吞吐遇到瓶颈，单库的IO能力已经饱和，备库同步延迟经常超过5秒
- 表字段过多，单行数据超过8KB，行溢出导致主键索引效率下降
- 业务维度清晰，比如订单表天然按用户ID或商家ID拆分，不拆反而难做冷热分离
行业共识认为,分表分库的核心不是“分”这个动作，而是分完之后如何不破坏业务查询的便利性，如果你的业务查询维度特别杂，今天按用户查，明天按商家查，后天又按时间范围扫，那分片键怎么选都是错的，建议先做数仓分层，而不是硬上分库分表。
分表分库和分区有什么区别？先搞清概念再动手
这是搜索引擎上被问烂了的问题,但很多人直到上线前才搞明白。
- 分区：逻辑上还是一张表，物理存储拆成多个文件，对应用完全透明，适合按时间归档、清理历史数据。
- 分表：把一张表拆成多张物理表，应用要感知表名变化，比如order_0、order_1，适合按业务维度分散读写压力。
- 分库：把表分布到不同数据库实例，连接数翻N倍，IO并行度提升，适合解决单库连接数上限和磁盘容量问题。
简单说,分区是减肥，分表是分家，分库是搬家，三者可以组合用，比如先按用户ID分库，再按月份分区，但每一层都意味着运维复杂度上升。
分表分库怎么实现：从分片键到迁移落地
第一步：选分片键，这是唯一没有后悔药的决定
分片键选错,后面所有努力白费，业界踩坑最多的就是这个环节，选分片键的硬性标准：
- 查询频率最高的等值条件优先，比如登录用户ID、店铺ID
- 数据分布均匀，取模不产生热点
- 不可变，不能今天按用户ID分，明天用户ID要改
- 能覆盖80%以上的核心查询，剩余查询走汇总表或ES
实操中,最常见的是user_id % 16或user_id % 64，注意取模数要选2的幂，这样后续扩容时能按位运算，只用迁移一半数据，如果你用10、12这种非2的幂次，扩容时基本等于全量重分。
第二步：中间件选型，别被技术名词带偏
目前主流方案就三类,各有各的适用场景：
| 方案 | 代表 | 适用场景 | 缺点 |
|---|---|---|---|
| 客户端分片 | ShardingSphere-JDBC | 新项目，团队能接受代码侵入 | 不能跨语言，升级要改代码 |
| 代理层分片 | MyCat、ShardingSphere-Proxy | 旧系统改造，多语言团队 | 多一跳网络，性能损耗约10% |
| 分布式数据库 | TiDB、OceanBase | 预算充足，希望彻底解放双手 | 迁移成本高，硬件要求高 |
我的建议是：Java技术栈选ShardingSphere-JDBC，它能和Spring Boot无缝集成，分片规则写在配置里，改造工作量最小，代理层方案适合你不想动业务代码的情况，但要做好性能损耗的心理准备。
第三步：数据迁移，别停业务那种
分表分库实践里,数据迁移是翻车重灾区，推荐用双写+校验方案：
- 上线前开启双写，新数据同时写入旧库和新库
- 用脚本分批把旧库历史数据导入新库,每批1000条，记录偏移量
- 每批导完做数据校验，比对主键和时间戳，不一致的重扫
- 全部导入完成后,灰度切换读流量，先切5%，观察异常
- 稳定运行一周后,关掉双写，旧库改为只读备份
整个过程最忌讳的就是“一把梭”，直接停机导数据，除非你的业务能接受凌晨两小时不可用，否则强烈建议双写方案。
第四步：改造SQL，哪些写法必死
分表之后,SQL写法有硬性约束：
- 不能再用自增主键，得换雪花ID或美团Leaf方案
- 跨分片join直接禁止，要么冗余字段，要么查两次再内存拼接
- 分页排序要小心，limit 10,20这种写法在分片下会得到错误结果，需要先查各分片再归并
- 事务范围缩小，只能保证单分片事务，跨分片事务要用Seata或本地消息表
分表分库会带来哪些坑？我帮你提前踩一遍
很多人只看到分库分表解决性能,没看到它引入的新问题，这部分内容值得你收藏。
全局主键用错，第二天就被数据搞崩溃
分库分表后不能用自增主键,这个大家都知道，但很多人直接用了UUID当主键，结果二级索引膨胀，插入性能暴跌，正确做法是雪花算法变体，比如用时间戳+机器ID+序列号，保证全局唯一且趋势递增，主流方案是百度的UidGenerator或美团的Leaf，别自己造轮子。
分布式事务，能不碰就别碰
跨分片扣库存、跨分片转账，这类操作在分库分表后举步维艰。业内专家指出，90%的业务场景都能通过“先本地事务，再异步消息”的方案规避强一致需求，如果实在躲不开，就引入Seata的AT模式，但要做好性能下降30%以上的心理准备。
扩容是第二个噩梦
你按16个分片规划,数据涨到1亿后，16个分片不够了，这时候怎么办？
- 停服扩容：最简单，但只能半夜操作
- 一致性哈希扩容：只用迁移部分数据，但路由复杂度上升
- 分片倍数扩展：从16扩到32，使用位运算，只需要迁移一半数据
最后一种方案是行业主流做法,所以前面我说取模数要选2的幂，就是为了这一步。
读多写少场景，先考虑缓存而不是分表
如果你的问题是“查询慢”，但写入量不大，那大概率是缓存没做好，而不是该分库分表了，Redis缓存、本地缓存、索引优化，这三个手段能解决相当一部分性能问题，分库分表是最后手段，不是第一选择。
分表分表分库实践，记住这几条就够了
分表分库实践走到最后,你会发现真正难的不是技术，而是业务理解，分片键是业务问题，不是技术问题；数据迁移是流程问题，不是代码问题；分布式事务是取舍问题，不是性能问题。
如果非要总结成一句话：分表分库的唯一目的是让核心查询更快，而不是让系统看起来更复杂，如果你的业务连分片键都找不出来，那说明还没到分库分表的时候。
分表分库实践常见问题解答
问题1：单表数据量多大才需要分表分库？
没有绝对阈值,大多数情况下，MySQL单表超过2000万行且索引命中后响应时间仍在500ms以上，或者单库连接数被打满，才需要认真考虑分表分库，如果只是慢查询，先优化索引和SQL，别急着动架构。
问题2：分表分库后怎么做跨分片查询？
业界通用做法是“分库分表+异构索引”，核心维度走分片键，非核心维度的查询走Elasticsearch或宽表层，少数团队会用MyCat的全局表机制，在每库冗余一份字典表，但数据一致性需要额外保障。
问题3：分表分库中间件选代理层还是客户端层？
客户端层（ShardingSphere-JDBC）性能好，无额外网络开销，适合Java开发者，但代码侵入性高，代理层（ShardingSphere-Proxy）对业务透明，适合多语言团队或遗留系统改造，代价是约10%的性能损耗和运维组件的复杂度，没有绝对优劣，只有契合度。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/556901.html
