1. 先别急着分看懂数据库的真实瓶颈做后端开发的这些年我几乎每年都会遇到几个一上来就问怎么分库分表的团队。他们描述的问题往往高度一致数据库CPU偶尔飙到90%以上、慢查询日志一抓一大把、主从延迟从几十毫秒涨到几秒、磁盘空间告警邮件每天半夜准时响起。然后大家就得出结论——该分库分表了。这个结论下得太草率了。先泼一盆冷水分库分表是数据库扩展方案里成本最高、运维最重、对业务侵入性最强的一种没有之一。一旦拆了join查询要改写、事务边界要重新梳理、全局主键要重新设计、数据迁移要做双写校验这一套组合拳打下来轻则三五个迭代版本全搭进去重则线上故障连着出。所以什么时候考虑分库分表这个问题的正确回答方式其实是反过来问你确定现在的瓶颈真的在数据库容量和读写吞吐上吗我在刚工作那几年踩过一个典型误区。那时候有个订单系统每天新增几十万条数据查询越来越慢我第一反应就是上分库分表。中间件选了、路由规则设计了、迁移脚本也写了一半结果一个细心的同事翻了翻慢查询日志发现80%的慢SQL都卡在一张表的索引上——那张表有个状态字段查询条件经常不带走全表扫描三百万数据扫一遍当然慢。后来只加了两个联合索引再把几个高频查询的SQL改写了一下数据库负载直接降了60%原定的分库分表方案全部作废。那之后我养成一个习惯在讨论分库分表之前先把数据库的瓶颈分类搞清楚。数据库扛不住流量通常只有三种情况存储空间不够了数据量已经逼近单库单表的物理上限读写性能不够了单机CPU、IO、连接数被打满查询延迟不可接受连接数撑不住了应用实例扩容之后每个实例建的连接池把数据库连接数耗尽。这三种情况对应的解决路径完全不同。第一种确实需要规模化拆分第二种要先看SQL和索引第三种通常靠连接池调优和数据库参数优化就能解决。如果没分清类型就动手拆库大概率是花了分库分表的钱治了一个换索引就能好的病。所以在这篇文章里我会把自己这些年总结的完整判断模型、压测定位方法、拆分路径选型逻辑以及真实踩过的坑全部拿出来梳理一遍。适合正在纠结要不要拆、什么时候拆的后端开发、架构师和技术负责人参考也适合那些刚被领导扔过来一句数据库慢了你看看的初级同学当作排查手册。核心思路就一句话分库分表是最后手段不是第一选项但对于真正到达瓶颈的系统它是绕不开的必修课。在我展开讲判断模型和实操细节之前想先明确一个概念上的区分因为很多人把分库分表当成一个词但实际它是两条完全不同的路。分表是把一张大表的数据拆到同一库里的多张物理表中解决的是单表数据量过大导致的性能问题分库则是把数据拆到多个数据库实例上解决的是单实例计算、存储、连接数上限的问题。分库不一定要分表分表也不一定非要拆库两者可以组合也可以独立使用具体怎么选要看你到底缺的是存储容量还是计算能力。这个概念后面还会反复用到先在这里立住。2. 从日常运维指标里找到系统撑不住的真实信号2.1 五个信号出现三个就要开始做预案如果你现在正管着一套业务系统又恰好是个偏保守的工程师不想等到线上出了故障才被动拆库那平时就应该盯运维监控里的几个关键指标。我在不同团队里待过发现真正科学的做法不是等CPU打满再拍板而是建立一套预警机制提前几周甚至几个月预判风险给自己留足准备时间。结合我个人的实操经验下面五个信号出现任意三个就应该进入分库分表可行性评估阶段了连接数超额。这是最容易被忽视的信号。我见过一个业务系统数据库配置的连接上限是2000但应用实例从5个扩容到15个之后每个实例的连接池默认都建了80个连接一算就是1200个再加上定时任务、后台报表、监控探活之类的额外连接高峰期直接打到1800多。数据库端一旦连接数耗尽新请求就只能排队等表现就是接口平均响应时间从50ms涨到2秒以上。这个信号出现的时候很多时候跟数据量根本没关系纯粹是连接管理出了问题。慢查询比例持续上升。MySQL的慢查询日志默认超过1秒才记录但实际业务里超过200ms的查询对用户体验就有明显影响。如果你发现slow log里的SQL数量从每天几十条涨到几百条而且排除掉索引失效、SQL写得太烂这些常规问题之后还在涨那大概率就是单表数据量累积到临界点了。我自己观察到的经验阈值是单表行数在500万到2000万这个区间时走索引的简单查询通常还能维持不错的响应一旦超过2000万即使索引设计合理B树层级升高带来的随机IO成本也会让查询延迟出现肉眼可见的劣化。锁等待和死锁频发。这个信号比较隐蔽因为大多数团队不盯锁相关指标。实际上当一张表的数据量和写入频率同时上升时行锁冲突的概率会显著增加。特别是那种先查后写的业务逻辑比如库存扣减、余额变更两条并发事务同时查同一条记录再更新很容易出现锁等待超时。我在监控后台用一条SQL就能查到锁等待情况SHOW STATUS LIKE InnoDB_row_lock_current_waits; SHOW STATUS LIKE InnoDB_row_lock_time_avg;如果InnoDB_row_lock_time_avg持续增大说明越来越多的写操作在排队等锁这时候要考虑的不仅是分库分表还得先审视业务逻辑里的事务边界是否过长。但反过来说如果表数据量到了千万级热行集中在一个账号上那分片把热数据打散也是有效的解药。磁盘IO升高。打开监控面板看一眼iowait或者磁盘读写延迟如果经常保持在80%以上说明数据库的读写已经逼近物理磁盘的极限。数据量增大、索引膨胀、buffer pool命中率下降都会导致每次查询要真正去磁盘读数据页。这时候加内存、换SSD是治标办法但如果你数据总量已经达到TB级硬件升级的边际收益会越来越低分库分表把数据分散到多个实例反而是性价比更高的选择。单表容量逼近物理上限。这是个很硬性的约束。MySQL单表能存多少数据其实没硬上限但实际操作中超过一定规模后运维动作都会变得很痛苦ALTER TABLE加字段要锁表备份恢复要按小时算主从同步延迟持续增高。我自己经历过一次噩梦一个10亿行的流水表要做字段变更在低峰期操作仍然花了将近40分钟期间所有写操作全部阻塞。从那以后我对单表容量的态度变得很保守。2.2 别拿感觉当依据先做一轮完整压测上面那五个信号只能说明系统有可能需要分库分表但真正做决策之前我强烈建议你先做一轮压测。原因很简单监控指标是日常情况的反映但日常流量和峰值流量对数据库的压力差距可能是数量级的。只有通过压测把数据库的真实上限找出来你才能判断现有系统的水位线离危险区有多远以及分库分表到底能带来多少倍的提升。压测的正确姿势是分三步走第一步确定压测目标。不能只压一个接口要挑核心链路里读多写多、涉及大表join、带事务的典型接口每个接口至少覆盖一个数据库访问场景。我当时做订单系统压测的时候选了五个接口订单列表查询、订单详情查询、创建订单、订单状态更新、日终对账汇总。这五个接口基本覆盖了读、写、事务、聚合计算四类典型负载。第二步用工具逐步加压。工具可以用JMeter、wrk、sysbench都行但关键是要做好监控配合。压测的同时盯住数据库的CPU、内存、IO、连接数四个核心指标找到它们各自被打满的点。比如某个接口QPS压到5000时数据库CPU到了95%但另一个接口QPS只有800就把连接数打满了这就说明两个接口的瓶颈类型完全不同对应的优化手段也完全不同。压测不是走个过场而是要把每个瓶颈点都定位清楚。第三步记录每个指标随并发上升的变化曲线。我个人的判断标准是当数据库CPU达到70%-80%时如果QPS已经达到业务预估峰值的2-3倍那说明离天花板还有空间先用优化手段撑着如果CPU刚到40%就让查询延迟翻了十几倍那就说明单表数据量已经大到让索引基本失效了这时候分库分表才是正确答案。这套压测做下来很多人会发现一个反直觉的结果真正让系统崩溃的往往不是数据量大而是某些远没到天花板的伪瓶颈。比如前面说的连接数打满是连接池参数配置的问题比如慢查询变多是索引碎片化和统计信息过期的问题比如IO飙升是buffer pool命中率太低的问题。这些问题用分库分表去解等于拿大炮打蚊子不仅成本高而且解决得不彻底。所以我一直跟团队强调一句话分库分表之前至少要做一轮成体系的性能优化排查。这个排查清单大概包括索引合理性分析有没有冗余索引、失效索引、SQL改写空间能不能去掉select *、能不能避免回表、缓存利用热点数据能不能进Redis、读写分离读多写少能不能从库扛读流量、归档策略历史数据能不能迁移到冷库。这套排查走完很多系统根本不需要分库分表就能再撑一两年。3. 先做小步优化还是直接上分库分表3.1 六层优化阶梯绝大多数系统根本走不到最后一步我刚入行的时候以为架构演进是一条路走到黑数据多了就分表表多了就分库分库还不够就上分布式数据库。后来见得多了才明白架构演进更像爬楼梯每一层都有它存在的意义和价值而且每一层都能解决特定范围内的问题跳层爬楼往往要付出额外代价。我把自己这些年用过的优化手段整理成一个六层阶梯越往上成本越高、对业务侵入越大只在下面层级都无法解决问题时才往上一层走层级优化手段适用场景典型收益实施成本第一层索引优化与SQL改写慢查询多、走全表扫描提升50%-80%低第二层缓存Redis等读多写少、热点数据集中减少80%以上读压力低第三层读写分离读远多于写、主库单点压力大提升3-5倍读能力中第四层数据归档与冷热分离历史数据占比高、冷数据少被访问降低30%-60%数据量中第五层垂直拆分分库业务模块耦合、不同模块负载差异大隔离资源、针对性扩容较高第六层水平拆分分表/分库单表数据量巨大、写入吞吐超单机极限理论上近乎无限水平扩展高这张表我在做技术评审的时候至少用过几十次。每次有人提我们要不要分库分表我就先问他前面五层做了没有大部分人的回答都是没做或者做了但没做透。这不是说大家技术不行而是业务压力推着人往前走很多时候根本来不及想能不能不拆就直接奔着最重的方案去了。所以这篇文章反复强调小步优化优先不是保守而是一种务实。3.2 先说透小步优化能解决什么有些读者可能会觉得既然这篇文章讲的是分库分表那前面那些索引优化、缓存之类的是不是跑题了我不这么认为。恰恰相反什么时候考虑分库分表这个问题的完整答案必须包含什么时候不该考虑分库分表。如果不把不该拆的场景讲清楚你永远不知道自己是不是做了个错误决策。举一个真实的例子。此前有个电商类客户项目用户表大概800万行订单表大约5000万行最明显的痛点是订单列表查询特别慢。他们的技术负责人拿着慢查询报告找到我说想上分库分表。我没有直接给方案先要了一份他们最频繁执行的订单查询SQL一看就明白了问题所在SELECT * FROM trade_order WHERE user_id 123456 AND status IN (PAID,SHIPPED,FINISHED) AND create_time 2023-01-01 ORDER BY id DESC LIMIT 10;这张表已经建了idx_user_id索引但注意status是个低选择性的字段而且SELECT *意味着每条记录都要回表取整行数据。当某个用户的历史订单特别多时即便走索引也要先扫出几千个主键再逐行回表这种随机IO叠加排序慢是必然的。改造方式其实不复杂SELECT id, order_no, amount, status, create_time FROM trade_order WHERE user_id 123456 AND create_time DATE_SUB(NOW(), INTERVAL 6 MONTH) ORDER BY create_time DESC LIMIT 10;改动集中在三点把SELECT *改成只取需要的列减少回表数据量把默认查询范围限制在最近6个月避免每次都去扫全量历史排序字段从id改成create_time配合联合索引(user_id, create_time DESC)让索引天然有序省掉filesort。就这么三步那个接口的P95响应时间从1.8秒降到了220毫秒。整张大表完全没有拆。缓存层面的收益同样巨大。还是那个电商场景用户订单列表虽然数据量大但用户的访问特征是旧订单很少翻、大多数人只看最近几页。于是我把订单列表页的首页数据缓存到Rediskey设计成user:order:list:{userId}:page:{pageNo}TTL设为30秒。用户翻第一页时大概率直接命中缓存只有翻到后面页才真正打数据库。这个改造做完数据库QPS直接降了50%以上。读写分离则是另一个经典解法。如果你的业务是明显的读多写少比如资讯类、内容社区类系统读取量是写入量的几十倍甚至上百倍那主库扛写、从库扛读是性价比极高的方案。只要主从延迟控制在业务可接受的范围内最常见的是1秒内延迟可见就能极大地缓解主库压力。但要注意一个陷阱读写分离解决不了数据量大、写冲突多的问题。如果一张表每天写入几百万行、主库CPU长期在90%以上那这个问题只能靠拆分来解决读写分离只是给拆分争取时间的手段。数据归档也不该被忽略。很多业务的表在物理上是一张表但逻辑上可以清楚地分成热数据和冷数据。比如订单表可以按完成状态划分未完成订单、近90天完成的订单是热数据保留在在线库超过90天已完成的订单归档到历史库。归档后在线订单表的数据量可能只有原来的20%-30%查询性能自然大幅回升。有人可能会担心归档后的查询怎么办实际业务里用户查历史订单的频率本来就很低把归档部分做成查询时从归档库异步拉取即可用户无感知。3.3 小步优化的边界在哪小步优化确实能解决很多问题但它也有明确的边界。总结起来就是如果系统已经出现以下情况小步优化的边际收益会急剧下降这时候再犹豫不决反而危险。第一种情况是单表数据量达到亿级且写入还在高速增长。之前有个互联网金融项目交易流水表一天新增800万行单表总量已经到3亿。聚集索引的B树深度已经超过4层即使主键等值查询都要经过4次磁盘IO才能定位到叶子节点任何一次范围查询都要扫描成百上千个数据页。这种体量下索引优化和缓存只能缓解读压力但写入按天增长的事实无法回避——你今天优化完了三个月后又回到原样。第二种情况是数据库写入吞吐接近单机物理极限。单台MySQL服务器的写入上限大概在每秒几千到一万多笔事务的量级取决于磁盘类型、binlog策略、事务大小和索引数量。一旦业务要求持续增长的写入TPS接近这个极限任何SQL层面的优化都没有意义了。此时需要的是把单机的写入能力水平扩展到多台机器上这就是分库分表必须出场的时刻。第三种情况是单库连接数资源成为扩容瓶颈。当应用实例数不断增加每个实例都要维持数据库连接池而数据库的连接数上限是有限的。即使你可以把连接数上限调高操作系统线程和文件句柄的开销也会随之增大最终单机无法承载。这时候把库拆开让不同的应用模块连不同的库本质上是在连接数维度做水平扩展。我个人的建议是当你判断小步优化的收益曲线已经明显变平而业务数据增长曲线还在陡峭上升时就是启动分库分表项目的最佳时间窗口。这个窗口通常早于线上故障爆发点但很多团队会误判现在还能跑就先不动直到故障真的出现才被迫做救火式拆分时间、成本、风险全都被动拉满。4. 分库分表的决策指南到底按什么标准判断该拆了4.1 六维评估模型不靠单一阈值下结论网络上流传着各种经验阈值比如单表超过2000万就要分表数据量超过2TB就要分库这些说法有一定参考价值但如果你直接照着执行很容易被带沟里去。因为分库分表不是只看数据量一个维度而是要综合评估多个因素。我把自己的判断模型总结成六个维度每个维度都设了临界线六个维度里有两到三个越过临界线才建议启动拆分计划。维度一单表数据量。这是最直观的维度但不是唯一维度。我之前接触过一个团队他们有个表只有几百万行但每行包含一个TEXT类型的字段存的是用户填写的长文本平均每行超过10KB。这张表总共也就几GB但查询时单行数据就占好几个数据页导致即使走索引回表成本也极高。而另一个系统单表有8000万行但每行只有几十个字节平均每行不到200B同样的索引条件下查询性能反而可以接受。所以关于数据量的判断不能只看行数还要结合行大小一起看。一个粗略的经验公式是单表总数据量 行数 × 平均行大小当这个值超过20GB到50GB时就要对性能做重点观察。维度二查询响应时间趋势。如果对一张表做固定模式的查询比如主键等值查询、唯一索引查询发现响应时间在过去三个月里逐步从10毫秒涨到100毫秒再涨到500毫秒这比任何绝对值指标都更能说明问题。因为它反映的是数据累积对索引结构、缓存命中率的持续恶化。我建议每个核心表都建一个响应时间水位线记录业务低峰期的P95查询延迟连续几周如果它呈现单调递增趋势那就要警惕了。维度三数据库实例的综合资源水位。包括CPU、内存、IO、连接数四个子指标。我个人的预警线是CPU持续超过60%、IO util持续超过70%、连接数持续超过80%上限、内存buffer pool命中率持续低于95%。任何两个子指标同时触碰预警线就说明单实例的扩展空间已经所剩无几了。维度四增长速率与趋势预判。这个维度特别关键但常被忽略。同样是5000万行的表如果一个业务年增长只有10%那可能再跑两三年也没问题但如果月增长就有30%那意味着不到一年就翻几倍就算今天性能还够用明天就必须拆。我通常用数据翻倍时间来量化这个维度当前数据量除以日均增长量得到X个月后数据翻倍。当X小于6时分库分表应该进入项目规划阶段当X小于3时建议立刻启动实施。维度五写入吞吐与热点集中度。有些业务虽然总体QPS不算高但写入集中在少数几个热点实体上。比如秒杀活动中一个商品的库存扣减、一个头部主播的销售记录所有写操作都打在同一行附近造成严重的行锁竞争和redo log争用。这种场景下单纯依赖数据量判断是失真的——数据量可能只有几百万行但写入瓶颈已经非常明显。水平拆分的作用就是把数据分布到多个实例热点也随之被分摊。所以判断时一定不要漏掉这个维度。维度六业务容忍度与运维成本。这个维度偏主观但极其重要。如果业务对可用性要求极高比如支付、交易链路每一秒的故障都可能造成资损那就要提前预留充足的安全边际宁可更早启动拆分。反过来如果业务可以接受一定的延迟和降级那就可以稍微往后撑一撑。此外还要考虑团队的技术储备有没有人熟悉中间件有没有人经手过数据迁移如果团队连分库分表中间件都没用过那更需要提前预演而不是等火烧眉毛才动手。4.2 评估模型实战演练两个真实case的对比光讲模型不落地等于白讲。我用两个亲历过的案例来演示这套评估模型怎么用。案例A一个内容社区系统的帖子表。当时表数据量约4000万行行平均大小约为1KB单表总量约4GB。查询延迟出现了缓慢上升的趋势P95从80ms涨到350ms。数据库CPU在高峰期约55%IO util约40%连接数使用约60%。日均新增约5万行按此测算数据翻倍时间约为4000万除以5万除以30天约合27个月。写入TPS约每秒300笔集中在少数热门帖子。业务容忍度中等可以接受偶尔慢查询但不可接受长时间不可用。评估结果六个维度里数据量逼近警戒但不算严重查询延迟趋势值得关注但增长缓慢资源水位尚有余量增长速率非常平缓翻倍时间27个月写入集中但总量不大。结论是暂不拆分先做索引优化和热点帖子缓存半年后复评。方案落地后系统运行稳定一年后数据量增长到6000万行仍然健康。这就是一个典型的不该拆的案例。案例B一个交易系统的支付流水表。表数据量约5亿行行平均大小约500B单表总量约25GB。查询延迟P95从150ms涨到2.5秒某些复杂查询甚至会触发10秒超时。数据库CPU在高峰期持续95%以上IO util接近100%连接数打满导致过两次瞬时拒绝连接。日均新增约600万行数据翻倍时间约80天5亿除以600万/天。写入TPS高峰期超过8000笔集中在几个大商户上。业务容忍度极低支付链路每慢一秒都会导致用户投诉和资金风险。评估结果六个维度里有五个越过临界线。结论非常明确——立刻启动水平拆分。我们用了两个多月完成了从评估、设计到迁移的全过程拆成32个分片后单分片数据量降到1500万行左右P95查询延迟回到180ms数据库CPU高峰降到40%以下。这个案例就是典型的必须拆。4.3 拆库和拆表怎么选先垂直后水平是通用路径如果你已经判断系统该拆了下一个问题就是拆库还是拆表垂直拆分和水平拆分怎么组合我自己的经验是大多数业务系统可以先走垂直拆分再按需做水平拆分这两步最好不要混着同时做。垂直拆分的核心思路是按业务模块拆库。把一个库里的用户、订单、商品、支付、日志等不同业务域的表分别放到独立的数据库实例中。这样做的直接收益有三个一是不同业务域的负载不再互相影响订单库的写入高峰不会拖垮用户库的查询二是每个库的规模变小管理、备份、扩容都更灵活三是可以针对不同库做差异化配置比如订单库用高IOPS磁盘、日志库用大容量廉价盘。实施前的工作是梳理表之间的关联关系哪些表是核心业务表必须同库哪些表只是辅助表可以拆走这个梳理过程往往要花不少时间。垂直拆分解决不了的问题是同一业务域的单表仍然太大。比如订单域里承载全部交易记录的核心订单表拆完库之后它依然是个5亿行的大表查询慢的问题没有根本改变。这时候就要做水平拆分——把同一张表的数据按照某个分片键sharding key散列到多张物理表中。水平拆分的方案选择我会在下一节详细展开。这里先说一个通用判断逻辑如果只是单表数据量过大导致查询和运维困难优先考虑水平分表同库多表如果除了数据量大还伴随单实例CPU、连接数、IO都逼近极限那就要考虑分成多个库让每个分片跑在独立的数据库实例上。前者解决表太大后者解决机器扛不住。另外关于拆分粒度的选择我倾向于一个务实的建议初期宁多勿少但要给未来留好扩展空间。假设你预估三年后单表数据量能达到1亿行计划每个分片控制在1000万行那需要10个分片。初期可以考虑直接分16片或32片留出未来3到5年的增长空间。分片数选少了后续二次扩容要迁移数据代价非常高分片数选多了一点点无非是管理上稍微复杂但计算、存储资源本来就可以按需利用。当然这也取决于你用的是自研路由还是成熟中间件后续章节会重点讲。5. 分片方案怎么选hash、range还是其他5.1 常用分片策略对比没有银弹只有匹配水平拆分方案设计里最核心的工作就是选分片键和分片策略。这一步选错了后面所有路都难走。我在技术评审里见过太多这种案例表拆分的时候随手选了id做分片键结果业务上最常见的查询条件却是user_id每次查询不得不走中间层的广播路由把所有分片都扫一遍性能比拆之前还差。所以选分片键的第一原则就是覆盖业务访问最频繁的查询模式。常见分片策略有四种各自的适用场景差别很大范围分片Range。按某个字段的连续区间切分比如按时间范围把订单表切成2023年一季度、2023年二季度、2023年三季度等多张表。优点是实现简单适合数据归档类的需求缺点是数据分布天然不均匀热数据集中在最近的时间段容易形成热分片而且跨分片的范围查询需要中间层聚合复杂度高。哈希分片Hash。按照分片键的哈希值取模映射到固定数量的分片上。比如分片号 hash(user_id) % 32。优点是数据分布均匀、写入能打散热点缺点是取模规则一旦定死分片数扩增时就需要重新映射迁移成本高。解决这个问题的方法是使用一致性哈希算法但实现复杂度也会上升。hash分片是最常用的水平拆分方案尤其适合订单、流水这类写入量大、热点集中的表。目录分片Directory。维护一张分片目录表记录分片键到分片号的映射关系。比如按照用户所属地域、团队ID等枚举值手动指定分片。优点是控制力最强可以针对不同用户数据量差异做权重分配缺点是目录表本身可能成为性能和可用性瓶颈而且需要额外的维护工作。这种方式适合分片键的取值空间很小或者分布极不均匀的业务。复合/多级分片。先按业务域做垂直分库再按时间或业务维度做水平分表形成两级甚至三级的分片结构。比如订单库 按月分表 再按user_id哈希分表。这种方案灵活度和精细度最高但设计复杂度和运维成本也最高。大多数高并发系统最终都会演进到这种方式但不建议一上来就做容易把自己绕进去。我用一张表把这些策略放在一起对比方便你做技术选型时对照分片策略数据均匀性跨片查询复杂度扩容复杂度典型场景范围分片低可能倾斜高低按范围切分即可日志、时序数据、归档表哈希分片高低理想情况只需命中一片高取模规则变化需迁移订单、支付流水、用户表目录分片可控按需分配中中租户隔离、枚举类分片复合分片高组合后较为均匀高高超大规模核心链路5.2 哈希分片的细节取模、一致性哈希和虚拟节点既然哈希分片是最常用的方案我展开把它的技术细节说清楚。最基本的实现是分片号 hash(sharding_key) % shard_count。比如shard_count 32那么一个user_id经过hash计算后会落到0到31号分片之一。这个方案在分片数量固定不变时非常稳定、高效中间层只需要一次求余就能定位分片。但它有个致命弱点扩容时需要迁移数据。假设一开始分了16片业务增长后想扩到32片原来hash(user_id) % 16得到0号分片的数据在新的规则下可能要被重新映射到0号或16号分片。这意味着几乎全量数据都要迁移线上执行起来风险极大。解决扩容问题的经典方案是一致性哈希。一致性哈希把整个哈希值空间组织成一个逻辑圆环数据落在哪个分片由它在这个环上的位置决定。当新增一个分片时只需要把该分片在环上前一个分片到后一个分片之间的数据迁移过去受影响的范围是局部的不是全局的。这个特性让它天然适合分片数会动态变化的场景。但一致性哈希也有自己的问题分片很少时数据分布可能很不均匀所以一般要引入虚拟节点的概念——每个物理分片在哈希环上生成一百个甚至几百个虚拟节点让数据分布更均匀。虚拟节点越多分布越均匀但路由表也越大查找效率略微下降实际工程里要在两者之间取平衡。另外要特别强调一个实际埋点哈希分片的数据均匀性受分片键的取值分布影响。如果某个用户产生的数据量是普通用户的百倍哈希分片依然会把这个大用户的所有数据都路由到同一个分片形成数据倾斜。这时候需要在分片键设计上做文章比如对超大用户做二级拆分先按用户维度分成主分片再按订单维度在主分片下继续分。这种方案的复杂度高但真有业务需求时又不得不做。我建议在分片键选型阶段就把这个风险考虑进去而不是等上线后发现某个分片磁盘暴涨再手忙脚乱地修。5.3 分片键选择不能只看查询频率还要看业务生命周期分片键的选择实际上是个多维决策。只覆盖高频查询是最基本的要求但它必须同时满足另外两个约束才算是好选择。第一个约束是分片键的值不可变或极少变。如果分片键是用户ID、订单ID这类创建后基本不变的值那是好选择如果你选了手机号而用户恰巧可以换绑手机号那么每次换绑都意味着数据要从一个分片迁移到另一个分片复杂度极高。我见过一个团队用手机号做分片键上线一周就遇到换绑手机号的需求最后只能加一层历史手机号映射表来兜底绕了好大一个圈子。第二个约束是分片键的取值空间要足够大且分布均匀。如果你用user_status这种只有几个取值的字段做分片键那结果就是数据严重倾斜到某几个分片上整个拆分的意义荡然无存。取值空间应该至少是分片数的十倍以上并且业务分布上不能出现极端的大头集中。我的实操建议是优先使用业务主键创建时间这种组合来设计分片键。比如订单表以order_id作为哈希分片键保证均匀同时在订单ID里嵌入时间信息比如订单号前缀带年月日这样既能均匀分布也能按时间维度做快速过滤。很多公司会把订单号设计成日期随机序列号的结构一方面方便人读另一方面也天然为分片提供了时间维度。补充一点关于广播表和字典表的设计。不是所有数据都需要分片。比如商品类目、支付渠道配置、地区列表这类数据量小、几乎所有查询都要join的表放在每个分片里各存一份冗余副本就行中间件会把这些表广播到所有分片。这样查询时本地join即可完全避开跨分片join的问题。我当时在交易系统里把十几个配置类表都设置成广播表省掉了大量跨库联查的麻烦。这里也提醒读者注意区分哪些表该分、哪些表不该分——不是所有表都应分片反而是只有真正的大表才需要分片。5.4 关于中间件选型自研还是用开源框架分片策略定了之后还有一个绕不开的问题分库分表中间件选什么。这本质上是自研路由还是引入开源框架的选择。我个人的看法是自研适合分片逻辑极简、团队经验丰富、有时间慢慢打磨的场景开源框架适合大多数业务系统能快速落地、少踩坑。开源领域最有代表性的是Apache ShardingSphere和MyCat前者从JDBC层切入以jar包形式嵌入应用对代码侵入相对较小后者是代理层方案独立部署在应用和数据库之间。我接触到的大多数团队选ShardingSphere的居多因为它面向Java生态支持度好功能覆盖也比较全。选型时的关键考量点有四个路由能力支持哪些分片策略能否自定义分片算法。分布式事务支持跨分片写操作能否保证一致性比如XA事务或柔性事务方案。全局主键生成方案内置还是需要集成第三方组件。运维配套有无控制台、监控、数据迁移工具社区活跃度如何。我记得在做那个5亿行支付流水表拆分项目时我们最初想自研路由因为觉得ShardingSphere太重量级。后来评估完工作量——包括路由算法、分布式事务、全局ID生成、多环境配置管理、监控告警至少得两到三个月的开发测试周期——果断改用了开源方案。事实证明这个决定是对的团队把精力集中在分片键设计和数据迁移上项目按期交付中间件本身没有成为瓶颈。当然对于分片规则极简单、团队有深厚自研经验的公司自研也不是不行但一定要想清楚自己能不能长期维护。6. 从设计到上线一次完整的分库分表落地全程6.1 预研阶段梳理全量表关系与访问模式做完决策、选定中间件之后真正的工作才刚刚开始。我把一次完整的分库分表落地拆成五个阶段每个阶段都有明确的目标和产出物。以我经历过的一个交易订单表拆分项目为例完整流程大概如下。第一步是梳理业务域与数据关系。把现有的所有核心表列出来标记出它们的关联关系、访问频率、数据量、增长速率。特别要标出哪些表会被高频join——这些表要么拆到同一个分片用相同分片键要么设置成广播表。我当时用了一个晚上拉着业务方和核心开发一起过了一遍全链路从创建订单开始到支付、发货、完成、售后每个环节涉及哪些表、哪些查询、SQL长什么样全部记录下来。这张表的关系图就是后续分片键设计的输入。第二步是确定分片键和分片策略。按前面章节讲的原则订单表选择了user_id作为主分片键——因为业务上最核心的查询是查某个用户的所有订单这个查询天然只落一个分片。同时订单ID里嵌入日期信息在分片内部按时间做局部索引优化。分片数量初步定为32个按当前数据量和增长速度测算每个分片控制在1500万行以下可以支撑大约3年的增长。第三步是设计中间件配置与全局主键方案。全局主键用雪花算法生成保证全局唯一且趋势递增。分片路由规则用user_id哈希取模。需要跨分片join的查询尽量改写为两次单分片查询然后在应用层聚合跨分片事务用本地消息表和TCC方案兜底不用强一致性的XA事务因为支付类系统对一致性要求虽高但更看重可用性和最终一致性。第四步是制定数据迁移方案。我们当时采用双写校验后切换的策略在旧表之外建立全新的分片表结构业务代码开始同时写旧表和新分片表利用一段时间的双写让新分片表积累了足够多的一致性基础数据然后把历史数据通过ETL工具按分片规则导入新表最后进行多轮数据校验确认无误后逐步把读流量切到新表最终下线旧表。双写期间如果出现写入不一致由对账任务定期扫描修补。整个迁移过程大约持续了两周线上没有停止服务业务方几乎无感知。第五步是上线与容量验证。迁移完成后不是直接宣布项目结束而是要对新分片集群做一轮完整的压测验证不同分片上的数据分布是否均匀、查询延迟是否达到预期、容量是否满足未来一段时间的需求。我们当时的验证结果是32个分片中数据量分布均匀度在±5%以内P95查询延迟从2.5秒降到180ms数据库CPU高峰从95%降到40%左右目标全部达成。6.2 迁移实操中的关键校验技巧数据迁移是整个落地过程里最容易出状况的环节。我在这里分享几个实操技巧都是踩过坑之后总结出来的。技巧一一定要做行数对账和抽样内容校验缺一不可。行数对账只能证明两边数量一致但无法检测同一行内容不对的情况。我见过一次迁移事故源库和目标库行数完全一致但某个字段因为编码转换问题全部变成了乱码业务方在使用时才发现。所以我们后来的标准做法是除了用COUNT(*)对账外还在源库和目标库各自随机抽取一定比例的数据行对每一行做CRC32或MD5校验比对校验值是否一致。技巧二控制迁移速率分批限流。历史数据导入最怕的是一次性全量灌入把分片库的写入带宽占满影响正在进行的双写业务流量。我建议迁移任务按分片逐个执行每个分片内的数据再按主键范围分批次每批次1000行左右批次之间间隔几秒让系统有喘息空间。同时监控目标库的QPS、延迟、磁盘IO一旦超过预设水位就自动暂停。技巧三双写不是简单写两份要做好幂等和延迟补偿。双写期间业务代码同时写新旧两套存储如果新分片表写入失败一定要有重试和补偿机制。我们当时用了一张双写对账表把双写失败的记录标记出来由定时任务每五分钟扫一次并进行补偿。这个机制看着简单但救过好几次火——毕竟双写阶段最怕的就是新表少了数据但旧表正常而业务在跑的时候往往没人发现。技巧四切换读流量前要做影子验证。正式把读流量从旧表切到新表之前先在灰度环境把一部分测试用户或低价值用户的查询路由到新表对比响应时间和返回结果。影子验证至少跑满三到五个业务高峰周期确认无异常后再扩大切流量范围。这比一上来全量切换要稳妥得多。6.3 拆分后必踩的坑和应对预案分库分表不是拆完就好了拆分之后系统会引入一系列新的问题我在每个项目里几乎都能遇到。提前把这些坑聊透能帮你省掉大量救火的功夫。坑一全局主键冲突。原来单库可以用数据库自增ID但分片之后主键必须全局唯一否则不同分片上的数据会出现主键重复。解决方案是前面提到的雪花算法ID或者使用中间件提供的分布式ID生成器也可以借助Redis的INCR命令自己生成。但注意不要直接用时间戳随机数简单拼一个ID在高并发下会有碰撞概率一旦碰撞就是脏数据排查起来非常痛苦。坑二跨分片join变成了不可能任务。这是一开始就要认识到的事实水平拆分之后如果两张表的分片键不同在数据库层做join几乎是不现实的。做法就是在设计阶段尽量让经常一起查询的表使用相同的分片键。如果实在无法避免就需要在应用层做两次查询再组装或者引入搜索引擎存储关联数据供查询使用。所以拆分前一定要做表关系梳理这个步骤不能省省了后面全是坑。坑三count统计和分页查询的精度问题。拆分后要统计总数不能简单汇总各分片的Local count因为并发写入时可能存在中间状态而且分布式系统里各分片返回的count是不同时间点的快照。我们当时把订单数量统计这一类需求做了重构实时统计改用性能计数器的近似值或者缓存增量值严苛的财务级统计则对分片库做一次性快照再汇总保证口径一致。坑四分布式事务的一致性保障。拆库后原来单库事务内能保证的多表写操作现在可能分布在多个分片甚至多个实例上。我的建议是优先把事务涉及的记录放进同一个分片也就是用同一个分片键如果实在无法避免跨分片事务根据业务场景选择柔性事务方案TCC、本地消息表而不是强一致XA事务。大多数互联网业务对最终一致性都是可接受的强一致性方案在高并发下往往得不偿失。坑五分片键低选择性的扫全片问题。如果一个查询条件不包含分片键中间件无法定位分片就只能把它广播到所有分片去执行再合并结果。这种操作会随着分片数量增多而越来越慢。解决思路是高频查询尽量都带上分片键确实无法带分片键的查询单独建一张辅助索引表存冗余的关联关系。比如根据订单号查用户ID这种反查场景可以维护一张order_id - user_id的小表先查到用户ID再路由分片。这些坑没有一个是新技术问题全是工程问题但工程问题往往比技术问题更磨人。如果你正准备启动分库分表项目我建议把这段话抄在小本子上拆分的价值在于突破了单机瓶颈但拆分的代价是永远失去了单库时代的一切便利。你要用架构上的复杂化换取性能上的提升这个交易值不值得取决于你前面章节建立的评估模型。7. 高频疑问与排查经验速查留给正在做技术决策的你如果前面那些内容你读下来觉得有点多我把这几年被问得最多的几个问题整理成了一个速查式的问答方便你在内部讨论时直接引用。问单表数据量到多少万一定要分表答不存在一个放之四海而皆准的硬数字。我的判断标准是先看性能劣化曲线持续压测或监控单表的P95查询延迟如果随数据量增长而线性劣化就该关注了。经验上行数超过1000万且单行超过1KB或者简单索引等值查询超过100ms就应该进入评估流程而不是被某个千万级的口诀牵着走。问分库分表能解决所有性能问题吗答绝对不能。它对单表数据量巨大导致索引层深和IO成本高、单实例CPU/IO/连接数打满这两个场景效果显著。但它解决不了SQL写得太烂缓存策略失效程序bug导致的全表扫描等问题。即便是拆分后的系统依然要做SQL审核和索引管理。问读写分离和分库分表冲突吗应该先做哪个答不冲突而且通常是先后关系。合理的路径是读写分离先行它改动小、见效快把读流量从主库卸掉让主库有更多资源应对写请求等写入量也大到单机无法承受时再做分库分表。拆分完成后的分片集群依然可以按主从架构部署继续保留读写分离的能力。问中间件选择上更推荐代理层还是SDK嵌入层答看你的团队情况和交付周期。SDK嵌入层如ShardingSphere-JDBC应用直连数据库额外延迟极小对DBA友好但要求应用自己管理分片规则代理层如ShardingSphere-Proxy、MyCat对应用透明但多一跳网络有一定性能损耗和高可用要求。如果团队偏业务开发、不想在每个服务里改代码代理层更合适如果团队技术能力强、追求极致性能SDK嵌入层更好。问分库分表之后如何做日常的数据统计和分析型报表答线上OLTP分片库不适合直接跑复杂的分析SQL。标准做法是从各分片同步数据到数据仓库如ClickHouse、Doris或Hive在仓库侧做数据整合、汇总和报表分析然后让报表系统只读仓库数据。这个ETL链路要在拆分方案设计时就规划进去不要等报表需求来了再临时补。问分库分表之后怎么备份和恢复答每个分片单独备份备份策略保持一致恢复的时候要按分片并行恢复并且确保各分片间的数据一致性。真实的灾难恢复演练至少每季度做一次不能只在纸面上写个预案。当年我们的支付流水库一旦故障DBA能在15分钟内把所有分片从备份恢复到线上就是因为演练做得足够多。这套问答是我个人判断框架的高度浓缩。你拿去跟团队过技术方案的时候可以直接引用但核心还是要回到自己业务的实际情况——世上没有一套标准答案能覆盖所有系统只有结合业务数据特征和团队能力的评估才能做出靠谱的决策。最后再分享一个我在多个项目里反复验证的体会分库分表的正确触发时机不是系统已经崩溃的时候也不是数据量还没到瓶颈的时候而是在小步优化已经走到尽头和未来增长可以量化预判这两个条件的交叉点上。在这个窗口期启动拆分你有充足的时间做设计、压测和灰度而不是在告警声中仓促上阵。至于那些已经明显逼近极限的系统我的建议是——别再犹豫了趁业务还在可控制的风险范围内果断行动。数据库拆分虽然疼但比起让业务在故障中被动断食提前做规划永远更划算。如果你正在为这个问题纠结希望这篇梳理能帮你少走一些弯路。