在做订单类系统时业务方经常一上来就喊“表太大了分库分表吧”。我通常不会马上开始拆而是先去看一组数据单表数据量有多少、单实例的CPU和IO压力有多大、高峰期慢查询占比高不高。只要这三个数字没到临界点强行分片的结果往往是查询没变快反而把路由、事务和扩容的复杂度全背到自己身上。所以围绕“分表分库分片策略选型”我想把一份从实际项目里沉淀下来的清单完整展开。会聊垂直拆分和水平拆分的边界、范围分片和哈希分片的适用场景、分片键怎么选、中间件怎么评估以及扩容迁移时最容易翻车的几个细节。这篇文章不是教材是一份可以直接拿去评审和开工的实操清单。1. 先想清楚什么情况下才需要动用分库分表1.1 别把分库分表当默认选项先看这三个硬标志刚接手一个订单系统时业务方上来就说“表太大了要分库分表”。我的习惯是先不看要不要拆而是先看三个数字单表数据量、单实例CPU/IO压力、高峰期响应时间。如果单表数据量还没到千万级CPU利用率平时也就20%慢查询主要是缺索引那你真正要做的可能是加索引、做归档、上缓存而不是拆表。我见过太多把一张300万行的表拆成32张结果查询没变快反而因为跨片查询和事务复杂度把自己绕进去了。分库分表真正要解决的是单库和单表已经扛不住的问题而不是设计上的“未雨绸缪”。哪些算“扛不住”我的判断标准有三条一是单表超过几千万行后索引层级加深写入和查询的随机IO明显变贵二是单实例连接数被打满业务还在持续扩张三是慢查询数量随着数据量线性上涨即使加了索引也压不住。这时候才需要考虑把数据拆出去。1.2 分库分表解决的三件事和它换来的代价分库分表本质上是拿复杂度换容量和并发。它一次解决三件事存储容量、连接数瓶颈、单个分片上的读写压力。但代价也摆在明面上原来一条SQL能搞定的事现在要考虑路由、聚合、排序、事务、自增ID。原来一个库备份恢复很简单现在几十个分片要一起管理。原来扩容就是加硬盘现在扩容要把数据重新打散。换句话说做分库分表之前脑子里得先有一本“复杂度账本”否则拆到一半会发现所有简单问题都变难了又没有能力把难问题收拾干净。我第一次带团队拆分订单库时中间件选型花了一周结果一个分片键选错上线两周就要补一张映射表救场。所以这篇先把策略讲透再谈选型顺序不能反。2. 拆库还是拆表垂直拆分和水平拆分的边界在哪2.1 垂直拆分按业务域把库切开先解释一个容易混淆的概念分表和分库是两个动作但经常一起出现。垂直拆分是按业务域把不同表放到不同数据库比如用户库、订单库、支付库、商品库各拆一套。垂直拆分解决的是“一个库承担了太多业务”的问题。所有业务表都在一个库里时某个核心表的慢查询会把其他业务的连接池拖垮跨业务的连接泄漏也会互相影响。拆成独立库以后每个业务域独占连接和IO扩容和故障隔离都更清晰。但垂直拆分有一个显而易见的天花板它并不能解决单表数据量还在增长的问题。订单库拆出去了可订单表该有几千万行还是几千万行。所以垂直拆分在我看来更像第一步它适合“业务域之间存在资源争抢”的场面而不是“单表已经大到跑不动”的终局方案。跨库JOIN也随之出现原先一个JOIN能搞定的事现在要么在应用层做二次查询要么引入宽表或聚合数据。2.2 水平拆分按数据行把表摊开水平拆分才是真正把单表数据量压下去的手段。它把同一张逻辑表按照某个规则拆成多张物理表比如把订单表拆成order_0000、order_0001……每一张表只保存一部分行单表体积和索引深度都能控制住。实际工程里分库和分表经常叠加使用先按业务域垂直拆再对核心大表做水平分片两个方向不冲突。水平拆分的关键在“规则”也就是分片策略。规则设计得好每个分片的数据量、热点、扩展性都舒服规则设计得差就会出现某个分片撑爆、其他分片闲着等于白拆。很多人在这一步就开始纠结中间件选型我反而建议先把规则写清楚到底用什么字段分、按多少片分、数据倾斜了怎么补救。规则定了再去选工具工具只是执行规则而不是反过来让工具决定你的架构。先想清楚这两个拆法的适用边界后面选型才不会跑偏。3. 分片策略选型四种主流策略怎么挑3.1 范围分片简单直观但小心热点堆积范围分片是最好理解的一种按某个字段的连续区间把数据切到不同分片。比如订单按创建时间切1月的数据放order_2025012月的数据放order_202502或者按用户ID区间切user_id 1-1000放一个分片user_id 1001-2000放另一个分片。优点非常明显实现简单适合时间维度归档范围扫描友好比如查询“某个月所有订单”可以直接落到对应分片不需要扫全部片。我做过的一个日志系统就用时间范围分片每天一个分片过期数据直接降存储非常省心。缺点同样致命数据热点容易集中。如果按时间切那当前时间点产生的所有写流量都涌向最后一个分片前面的分片闲得发慌后面的分片被写垮。业务数据一旦有明显的“只写最近”特征范围分片会制造一个天然的热点分片。按用户ID区间切也一样新用户ID不断变大新区间分片永远是热点。所以范围分片更适合“时间序列、冷热分明、读写相对均衡”的场景。用在交易类核心表上除非你能接受热点分片单独扩容否则是下策。3.2 哈希分片均匀分布的常选方案但扩容是硬伤既然范围分片怕热点那就用哈希把数据打散。常见的做法是取分片键的哈希值再对分片总数取模例如hash(order_id) % 16这样数据在大概率上能均匀分布到16个分片。如果分片键本身就是数字且分布均匀比如用户ID也可以直接user_id % 16但要注意直接取模对分片键的分布质量要求很高。用户ID如果是从1连续递增的自增ID取模后基本均匀换个不规则的号码却可能分布极差。更稳妥的方式是先做一次哈希散列再来取模。哈希分片最大的痛点是扩容。原来16个分片数据按%16打散要扩到32个分片规则变成%32几乎所有数据行的路由结果都会变。这就意味着扩容时必须全量迁移、重算路由而不是像范围分片那样只动新增区间。为了缓解这个问题才有了后面的“预分片”和“一致性哈希”思路。哈希分片是业务交易系统里最常见的选型因为流量均匀是第一诉求。但在选它之前一定要先想清楚未来三年有没有扩容计划以及你愿不愿接受迁移成本。我的建议是分片数一次性规划得大一些宁可初期分片冗余也别留一个三年后必炸的扩容坑。3.3 一致性哈希扩容友好但要理解虚拟节点一致性哈希是在“减少扩容迁移量”这件事上比普通取模聪明得多的方案。它把整个哈希空间看成一个环分片节点落在环上数据也按哈希值落在环上然后顺时针找最近的节点存储。节点变化时只有环上相邻区间内的数据需要移动而不是全量迁移。真实项目里还会引入虚拟节点。因为节点少时哈希环上的节点分布可能很不均匀某个节点会承担远超平均的数据量。引入虚拟节点后每个物理节点对应几十个甚至上百个虚拟节点让环上的数据分布更平滑。不过我要泼一盆冷水一致性哈希在数据库分库分表场景中并没有像缓存场景那样普及。原因是它让数据位置不再是一个简单可计算的公式路由的推导复杂了跨分片查询时很难通过分片键快速确定目标节点。它更多用在缓存、任务分配、消息队列消费组等节点频繁变化的场景。如果你在做分库分表选型把它当成“了解但慎选”的选项即可除非你的分片节点确实要频繁上下线。3.4 时间分片与组合策略别让路由变成一座迷宫实际项目里很难用单一策略解决所有问题所以我更建议做组合策略。比如“时间范围 业务维度哈希”日志表先按月切分每个月再按tenant_id哈希成4个分片这样既能按月归档又不会让单月数据集中在同一个分片。组合策略要特别注意路由的可解释性。查询时必须能根据查询条件快速定位到少数几个分片如果条件里没有时间或没有租户ID路由只能扫描所有分片性能直接退化成全表扫。我在一次选型复盘里见过一个案例分片规则是“年份取模 城市哈希”结果运营查数据时经常只提供用户昵称没有年份也没有城市每个查询都触发全分片扫描线上慢查询瞬间爆表。关于时间分片还有一个细节时钟回拨或业务数据补录。历史数据如果被重新写入修改时间变了路由位置也跟着变容易造成同一行数据在不同分片之间漂移。处理办法是把分片键用“创建时间”而不是“修改时间”并且在规则里固化“数据归属分片后不迁移”的原则。策略的复杂度可以高但查询路径不能迷雾重重。4. 分片键选型这一环做错后续全是补丁4.1 一个好的分片键至少要满足四个特征分片策略定了接下来就是选哪个字段当分片键。这一步我习惯用四个特征来过滤候选字段区分度足够、分布均匀、不会频繁修改、查询条件里高频出现。区分度不够的字段比如只有“男/女”两种值分片只能切成两堆热点一眼可见。分布不均匀的字段比如地区ID发达城市数据量远超小城市分片照样倾斜。频繁修改的字段比如用户手机号一旦换号就要把数据行迁到另一个分片代价极高。查询条件里不高频的字段比如只在后台报表里用的字段用来分片会让前台查询全部跨片。以订单表为例候选字段有user_id、order_id、shop_id、create_time。如果是 C 端订单系统user_id通常是首选因为用户查自己的订单是最常见的路径如果是 B 端商家后台shop_id反而更合适。选分片键不是在选“最全局的字段”而是在选“最高频查询路径里的稳定字段”。4.2 如果主查询条件不是分片键就用基因法兜底很多时候你确实不得不用user_id分片但业务里又经常出现“按订单号精确查询订单”的场景。订单号和用户ID怎么对齐最土的办法是建一张order_id - user_id的映射表先查映射再路由但多一次查询总让人不爽更聪明的做法是基因法。基因法的思路是把用户ID的部分信息“注入”订单号。比如用户ID取模得到分片号user_id % 16 3生成订单号时让订单号的后4位也携带这个分片信息这样拿到任何订单号都能直接从订单号本身算出它应该落在哪个分片不需要先查映射表。代价是订单号不再是简单的自增序列长度可能变长可读性变差。基因法牺牲了一点优雅换来了路由性能。类似方案还有“冗余分片键”比如订单表既存order_id又冗余user_id按订单号查时先算出user_id落点再访问分片。这些都属于分片键选型问题的补救措施但如果你在一开始就把分片键选对了补丁可以少打很多。4.3 分片键改不动时唯一有效兜底冗余路由表如果分片键已经上线业务又要求支持按另一个字段查询比如经常按“手机号订单号”组合查不要试图把所有查询条件都塞进分片规则那样会陷入路由平衡的怪圈。我建议维护一张冗余路由映射表这张表记录“业务标识 - 分片编号”查询时先查路由表再访问真实分片。路由表本身数据量不大可以单库存放写入在业务创建数据时同步维护读取可以先走缓存。它多引入了一次查询但把路由复杂度控制在了可接受范围。我见过太多团队为了让两个查询条件都能直接路由把分片规则做成“先按A分片再按B分片”最后查询时只要缺一个条件就得扫全部片属于典型的过度设计。5. 组件选型分片规则交给谁执行5.1 中间件形态怎么选客户端型还是代理型分片策略只有落到执行层才有意义。这一步的主要选择是在客户端型中间件和代理型中间件之间做取舍。客户端型中间件以代码库形式集成进业务应用应用通过它访问数据库分片逻辑由它在驱动层完成代理型中间件以独立服务形式部署业务应用连接的是代理代理再把请求转发给真实数据库。两种形态没有绝对好坏关键看团队掌控力。客户端型部署轻、性能开销小、SQL兼容性可以做到很细但升级要改业务应用排障要看应用日志代理型集中治理、对业务代码侵入小适合跨团队统一管理但多一层网络转发会增加一点延迟和高可用复杂度。我做分库分表选型时有个原则团队越早期越优先客户端型因为它灵活方便在策略上快速迭代团队规模大了、多个业务线共用数据库基础设施时才引入代理型做统一接入。不要一上来就搭一个大而全的数据访问层选型越重调整分片策略的成本就越重。5.2 一张功能清单才是真正的选型表工具名只是表象真正要对比的是功能清单。我给团队做过一次标准评估维度整理出来就是下面这张表选型维度要重点确认的问题SQL兼容性子查询、多表JOIN、分页、聚合函数是否被支持或改写分布式事务是否支持XA、TCC或本地消息表业务强一致等级能否满足读写分离是否支持多主多从、读写压力分离后路由规则是否可自定义分片策略是否原生支持Hash、Range、按时间、自定义分片算法扩容工具是否提供在线迁移、分片合并/拆分、数据一致性校验工具监控能力是否能看到每个分片的请求量、慢查询、连接数团队成本引入后需要多少人能玩转排障是否需要专门专家我特别提醒SQL兼容性要拿真实业务SQL去测而不是看文档。很多中间件宣传支持标准SQL实际跑业务里那种几百行的报表SQL时改写得一塌糊涂。选型前整理一份业务高频SQL清单覆盖增删改查、分组排序、分页、多表JOIN让备选方案全部跑一遍比读十篇对比文章都管用。选型过程还要做一个“分片策略演练”把线上流量做一次压测回放观察中间件的CPU、内存、连接数看它在高峰期的表现。工具最终是辅助做决定以前一定要先验证分片策略在工具上的实际表现而不是只看功能列表。6. 扩容与迁移从双写到灰度切流6.1 三种扩容方式的利与弊分库分表之后扩容一定是绕不开的问题。常见的三种方式是停机迁移、双写双读、平滑迁移。停机迁移适合老项目能接受短暂停服的场景做法是停流量、备份数据、按新规则重排、重启服务。它能保证数据一致性最简单但停服时间跟数据量成正比数据量一大时间窗口就不可控。双写双读是主流平滑方案新老两套结构并存业务先把写操作同时发给老库和新库再通过异步任务把历史数据回填到新库数据校验通过后把读流量逐步切到新库。双写听起来简单细节却很磨人老库更新成功而新库失败怎么办、两边的自增ID冲突怎么办、数据校验用什么口径对账这些都算常见问题。平滑迁移的核心是灰度切流不要一次切100%先切5%的流量试运行观察错误率和延迟确认稳定后再逐步放大。我在一个订单项目里是分了三轮切流第一轮切内部测试账号第二轮切5%线上读流量第三轮等校验一致后再切全部写流量。顺序一旦搞乱回滚成本会非常高。6.2 预分片用一层桶映射把扩容成本降下来预分片是很多团队容易忽略的思路。它的做法是提前把逻辑分片数设大比如一次性分成1024个逻辑分片然后用一张“桶映射表”把逻辑分片映射到物理实例逻辑分片范围所在的物理库shard_0 ~ shard_63order_db_0shard_64 ~ shard_127order_db_1shard_128 ~ shard_191order_db_2业务写入时先根据分片键的哈希值确定落到哪个逻辑分片再通过映射表找到物理实例。扩容时不需要重算业务数据的哈希位置只需要调整映射表把一部分逻辑分片挪到新的物理实例上。映射表可以在内存里维护一份也可以做成配置下发运维变更就成了改配置文件而不是全量迁移。预分片的缺点是初始就有很多空闲分片管理成本略高比如连接池、备份任务都会随之增多。但它换来的扩容平滑性太值得了。我的默认建议是分片数往未来三年的数据量估不要图省事只分16片否则后面每次扩容都是一次大迁移。6.3 迁移中的三个硬核校验点迁移过程中最容易出错的是“对账”这一环。我通常会在回填完成后做三件事总数校验、抽样校验、变更流校验。总数校验比对老库和新库各分片的数据行数抽样校验抽查特定ID在老库和新库中的字段值是否完全一致变更流校验则观察回填期间新产生的数据是否通过双写机制准实时同步到新库。这三个校验全部通过后才轮到切读流量。即使如此我也建议把新库的慢查询监控和失败率监控提前接好一旦切流后出现异样能立刻在监控上看到而不是等业务投诉。迁移最大的坑不是工具不给力而是没有定义“什么才算迁移成功”的验收标准导致数据都切完了团队心里还没底。7. 分库分表后的经典痛点与排查清单7.1 分布式事务先问业务能不能接受最终一致分库分表后原来一个本地事务里更新订单和扣库存变成跨库跨服务操作本地事务已经管不住了。处理方案常见的有XA强一致、TCC补偿、事务消息和本地消息表。我的建议是先问业务上的强一致性要求到底有多强。很多场景根本不需要分布式事务而是可以改成“先写一条状态数据再异步处理”应用层通过消息表记录事件消费端做幂等处理出现问题就重试最终能达到业务一致。真正需要强一致的场景比如账户扣款才值得引入TCC这种方案因为它的开发成本和排障难度都不是一般团队愿意承担的。工具能开箱提供分布式事务是加分项但在选型时一定要看它的事务协议和业务侵入程度避免用了一个自研很重的事务框架改不动、也查不了。7.2 跨分片查询与分页能汇总尽量汇总别硬扛分库分表之后一条SQL本来能完成的排序分页现在必须从每个分片分别查出数据后在应用层合并这也带来两个麻烦排序要重排深度分页要把数据全拉出来再翻页否则会变成慢查询。这不是完全无解。常见做法是把需要跨片聚合的数据沉淀到汇总表或宽表比如订单统计报表每天由定时任务从各分片汇总到统计库查询直接打统计库再比如全文检索需求数据同步到搜索系统后端检索不直接扫分片。如果你只是想按订单状态查列表还可以考虑“分页路由优化”只查目标分片而非全部分片前提是你能把查询条件转换成确定的路由条件。这个前提往往不成立所以对大多数团队来说设计时就该意识到复杂分析型查询不要期望在分片数据库上硬扛而是设计好数据出口。7.3 全局唯一ID别用自增ID硬扛分库分表后每个库各自维护自增ID不同库之间会出现重复ID全局唯一ID就成了必选项。最常见的方案是雪花算法64位里包含时间戳、机器ID、自增序号趋势递增且全局唯一。另一种是号段模式数据库集中生成一批号段业务应用拿号段后在内存里自增性能和唯一性都兼顾。雪花算法的坑主要在时钟回拨。一旦机器时间回拨生成的ID就可能重复。成熟生产环境会用延迟等待、备用序列、时钟同步等方法兜底。号段模式的坑则是中心库的可用性和号段分配的高并发性能需要做好缓存和熔断。我在项目里有时更倾向号段模式因为它对团队理解成本最低也不容易被时钟问题坑到。7.4 问题排查速查表一线摘出来的经验分片系统出问题时现象往往被中间件包装过定位起来很费劲。下面这张表是这几年排查问题的高频路径典型问题可能原因排查思路某个分片打满其他分片空闲分片键区分度差或值有明显热点查每个分片的数据量分布检查分片键冷热慢查询数量飙升但单分片负载不高跨分片扫描缺少确定的拆分路由条件打开中间件路由日志分析SQL命中了几个分片分布式事务经常回滚事务实现中对业务幂等处理不到位看事务参与者日志重点对补偿逻辑做幂等验证扩容后数据对不上双写失败、回填任务丢失、映射表更新时机不对按“总数校验、抽样校验、变更流校验”三项逐一排查数据倾斜严重分片键本身分布倾斜或虚拟节点设置不当统计分片键的TopN值把热点值的路由单独拎出来处理这张表不是万能药但能帮你在问题发生时先缩减排查范围。平时也要把中间件的路由日志和分片延迟监控提前打开否则出了事再临时加日志现场已经被污染了很难再还原。8. 收尾把选型清单沉淀成团队的固定动作我做了这么多次分库分表最大的体会是策略选型比工具选型重要分片键比中间件重要迁移前的对账比迁移过程重要。很多人拿着“分库分表”四个字就开干结果中间件、分片键、扩容全被推着重来一遍。所以现在我做任何系统都会强制先出一份分片策略选型清单数据量预估、业务查询路径、分片键候选、分片策略对比、扩容计划、迁移验收标准。清单写完后评审时第一时间请有经验的同行看分片键和查询路径而不是只看工具名。这个动作看着朴素却帮我挡住了至少三次灾难级的返工。如果你正要做分库分表不妨先拿清单把方案钉下来再动手别让“分片”两个字从一开始就变成一个深坑。