做后台开发这些年数据量上去之后大家讨论最多的技术话题之一就是分库分表。但很多人刚开始接触时很容易被一堆名词搞晕垂直拆分、水平拆分、分片键、路由规则、广播表、分布式事务……听着都熟串起来却总是差一口气。尤其是分库分表中间件很多资料上来就讲 API 用法却不说清它内部到底做了什么。这篇文章就把这些名词和中间件原理串起来讲一遍从单机瓶颈讲到拆分策略从 SQL 解析讲到结果合并适合刚接触分库分表、准备做技术方案或者面试前系统过一遍的同学。1. 为什么做分库分表先搞懂单机数据库卡在哪1.1 数据库实例的瓶颈往往不是磁盘而是连接和内存很多人以为数据库扛不住是磁盘容量不够其实在生产环境里最先告警的通常是连接数、CPU 和内存其次是 IO 延迟。一个关系型数据库实例能同时维持的连接数是有限的绝大多数业务系统使用连接池访问数据库比如配置 50 个连接但业务高峰期需要 100 个并发事务那另外 50 个请求就只能在连接池里排队。连接池最早被打满数据库 CPU 还不一定到了 80%这是非常常见的现象。内存方面数据库会把热数据和索引放进缓冲池单表数据量越大索引体积越大缓存命中率就会越低。一旦走磁盘 IO随机读的延迟会大幅上升原来单条查询只需 2 毫秒数据量翻几倍之后可能要 20 毫秒。这还没有算锁竞争。单表数据量大时同一行或者同一个索引块被并发访问的概率越来越高锁等待时间会显著增加数据库吞吐量跟着往下掉。1.2 分库解决并发压力分表解决单表压力分库垂直拆分/水平拆分的核心目标是降低单个数据库实例的负载把连接数、磁盘 IO、CPU 压力分散到多个实例上。比如用户库、订单库、商品库拆成三个独立实例每个实例的连接池都是独立计算互不挤兑流量再大也只是各自扛各自的不会互相拖垮。分表的核心目标则是降低单表的数据量和索引体积通常是在同一个库内把一张大表按行切分成多张小表。表变小之后索引层数变浅扫描的数据页更少锁粒度也相对更小。很多团队做分表是为了解决一张表几千万行甚至上亿行时的查询延迟问题而分库更多是为了解决实例层面的资源争抢。所以选择拆分方式前先想清楚痛点在哪如果是连接数打满、CPU 常年高位优先考虑分库如果是单表扫描慢、维护成本高、索引太大优先考虑分表。实际项目里分库和分表往往结合着用先按业务把库拆开再针对核心大表做水平分表。下面这张表可以帮你快速判断压力来源主要表现拆分方式解决的问题数据库连接数不足连接池队列堆积、应用超时分库多个实例分担连接压力单表数据量过大SQL 扫描慢、索引深度变大分表缩小单表体积和索引体积存储容量不够磁盘使用率告警分库把数据分散到多台机器锁竞争严重并发更新同一行/同范围分表/分区降低锁冲突概率这里说的“分库”更多是指把一个系统里的业务数据拆到不同的库甚至不同的实例上而不是同一台机器里建多个数据库。如果还是同一台机器磁盘和内存仍然共用连接数倒是可以翻几倍但 CPU 和 IO 压力依旧不减。真正的分库一般会配合独立部署或者至少放在不同的物理机/不同存储节点上。2. 分库分表的结构垂直拆分、水平拆分、分片键与路由2.1 垂直拆分看着简单但业务边界是最大难题垂直拆分的通俗说法是“按列拆”把一张宽表拆成多张窄表。比如订单表里有订单基本信息、商品明细、支付信息、物流信息这些字段在一个表里查询时光靠二级索引很难完全覆盖可以把订单基本信息单独放一张表商品明细单独放一张表支付信息和物流信息也各拆各的。这个思路在拆库层面也是一样按业务模块拆用户相关表放一个库订单相关表放一个库商品相关表放一个库本质上就是垂直拆分。垂直拆分的难点从来不在 SQL 怎么写而在业务边界的划分。拆完库之后原本一条 SQL 能完成的 join 查询往往就没了得改成多次查询。比如订单表需要关联用户信息如果用户表在另一个库代码里要么分别查两次要么在订单库里冗余一份用户基础信息副本。边界划分得好不好直接决定后续开发和维护复杂度。2.2 水平拆分靠分片键分片键决定数据去哪张表水平拆分是“按行拆”同一个表的数据按规则分散到多个结构完全相同的分表中。拆分规则的关键是分片键也叫分片字段。分片键的选择会直接影响路由是否均匀也在很大程度上决定了系统能不能扛住后续流量。分片键需要满足高频查询条件。比如订单表几乎所有的查询都带 user_id那就把 user_id 作为分片键同一个用户的订单落在同一张分表里查询只需访问其中一个分片效率最好。反之如果选了一个极少出现在查询条件里的字段比如订单备注类型那大部分请求就都会走全分片扫描分表效果大打折扣。路由规则最常见的三种取模分片编号 分片键的哈希值 % 分片数量。简单直接但分片数量一旦固定扩容时数据迁移相对麻烦。范围按时间区间或 ID 区间划分比如 2024 年的订单放 2024 表2025 年的订单放 2025 表。实现简单扩容方便但可能造成热点。一致性哈希把分片键哈希后映射到一个环上扩容时只需要迁移部分数据对业务侵入小但实现复杂度更高。取模路由虽然简单但真的不建议拍脑袋定分片数量。前期分 8 张表数据涨到一定程度要拆到 16 张原来 user_id 取模 8 的结果全部要重新计算数据迁移和双写非常痛苦。所以如果明确后面会扩展一开始就应该用某种方式预留分片空间或者直接采用一致性哈希方案。2.3 广播表和绑定表专门处理复杂查询水平拆分之后不是所有表都应该拆分。像商品分类、区域字典、配置参数这类数据量小、读多写少的表如果拆开反而会让查询变成灾难。解决办法是把这类表在每个分片上各存一份这种每个分片都有的表叫广播表也叫全局表。中间件在涉及广播表的 SQL 执行时会把广播表的数据合并或者直接缓存一份在应用侧避免每次跨节点查询。绑定表则是针对连表查询的一种优化。如果订单表和订单明细表都按 user_id 做水平拆分并且拆分逻辑完全一致那同一个 user_id 的订单和明细一定落在同一个分片上。中间件在改写 SQL 时可以把这个 join 改成单分片 join性能接近单库单表。绑定关系需要在中间件配置里显式声明。3. 分库分表中间件的核心原理一条 SQL 从进入到返回的完整过程3.1 两种主流的中间件架构模式分库分表中间件通常分为代理模式和客户端模式两种。代理模式是独立部署一套服务应用连中间件中间件再连后端数据库。应用只感知到一个统一的数据库端口分片逻辑全部封装在代理服务里。这种架构的好处是业务代码侵入少语言无关坏处是多一跳网络延迟会略高而且代理节点本身是高可用要重点关注的组件。一旦代理性能不够整个数据层都会被拖慢。客户端模式是把分片逻辑封装在 SDK 里应用直接连接真实数据库。好处是减少了中间一跳查询路径短坏处是每个业务服务都要引入 SDK配置升级时要跟随应用发布跨语言的团队很难复用。两种模式各有适合场景。小团队希望快速接入、不想每个服务改代码代理模式更合适团队规模大、对延迟敏感、基础设施统一客户端模式更常见。3.2 SQL 解析与物理 SQL 改写中间件直接面对 App 发来的逻辑 SQL第一步就是做词法解析和语法解析把 SQL 拆成抽象语法树。中间件语法解析的目的和一般数据库不太一样它更关心三件事查询目标涉及哪些表、分片键是什么值、是否包含了聚合或者排序。比如有一条 SQLSELECT order_id, amount FROM order_table WHERE user_id 9527 AND status 1;如果分片键是 user_id路由规则是取模 16那么9527 % 16 7这条 SQL 会被改写为执行在分片 7 上的物理 SQLSELECT order_id, amount FROM order_table_7 WHERE user_id 9527 AND status 1;如果查询条件里没有 user_id中间件无法定位具体分片只能把这条 SQL 广播给所有分片SELECT order_id, amount FROM order_table_0 WHERE status 1; SELECT order_id, amount FROM order_table_1 WHERE status 1; ...改写后的 SQL 会并行发送到各个目标分片等待结果返回。注意中间件并不会帮业务回答“应该用哪个分片键”这是设计阶段就得确定好的事。如果一个查订单详情的接口不带 user_id 也没有订单号映射关系那系统就只能全分片扫描性能大概率比单表还差。3.3 分页排序与聚合结果合并如果说路由是中间件的门面那结果合并才是最考功力的地方。先看 count 操作。SELECT COUNT(*) FROM order_table在分片场景下中间件要对每个分片执行 count然后把所有分片的结果累加。COUNT 这种简单聚合还能直接加但AVG就麻烦了绝对不能直接对分片平均值再取平均必须先把每个分片的SUM和COUNT拿回中间件层算完总数之后再做除法。排序和分页就更微妙。比如SELECT * FROM order_table ORDER BY amount DESC LIMIT 10;如果分片键是 user_id路由会广播给所有分片。每个分片都返回各自金额最大的 10 条中间件把所有数据集合到一起后还必须重新排序再取前 10 条。这里有个很容易踩的坑为了省内存有人在中间件里对每个分片只取 10 条然后汇总排序这个办法在大数据量下确实常用但它不是万能的。如果需求变成了LIMIT 1000, 10每个分片就不能只取 10 条了否则最终结果是错的。正确做法是每个分片取offset pageSize条汇总排序后再切分页页。聚合函数也一样GROUP BY之后的分组统计必须等所有分片的结果全部回来后才能做二次聚合。中间件的内存消耗会随着分片数量和结果集大小增长这也是为什么很多人说分库分表之后最怕统计类报表查询。4. 分库分表后必须面对的难题全局主键、分布式事务、跨分片关联4.1 全局主键生成方案分库分表之后单表自增主键直接失效因为多张表之间会撞号。全局主键需要同时满足唯一性、趋势递增和尽量短的位数。业界方案主要有这么几类方案优点缺点适用场景UUID 字符串本地生成、部署简单过长、无序B树索引写入性能差内部非核心链路时间序发号器趋势递增、生成性能高依赖时钟时钟回拨会产生重复高并发订单号数据库号段可批量取号、实现简单需要维护号段表多一次网络交互中小规模号段内存取并发高、间隔可控需要额外进程/接口大规模全局 ID很多团队会选时间序发号器的思路64 位分成时间戳位、机器位和序列位在一定范围内保证趋势递增。应对时钟回拨的办法也简单专用于发号的机器本身几乎不做时间校准或者保存上次分发时间如果发现时钟回拨到之前的时间就暂停服务等待时间追平。用时间序发号器时还要注意ID 是按位生成的业务如果直接用这个 ID 做分片键要注意取模后的均匀性。时间戳高位小时ID 整体是大体递增的但取模后不一定均匀前期分片热可能还不明显量大了之后需要尽快做均匀性验证。4.2 分布式事务能不用就不用用也要分场景分库之后原本一个本地事务跨到多个库就成了分布式事务。分布式事务方案有两阶段提交协议有一致性更强的实现也有补偿型方案。两阶段提交协议能保证强一致但性能损耗大协调者在事务期间要锁资源失败后还要回滚。如果核心链路经常大并发写不建议大量使用强一致方案。对大多数业务系统来说真正的需求往往能通过“最终一致”来解决。比如下单减库存拆到库存库和订单库先本地记录一条操作流水异步发送消息库存服务消费消息去执行扣减扣减失败就靠重试或补偿任务最终补上。为了保证可靠性本地消息表和消息中间件配合是常见的做法业务操作和消息写入同一个本地事务消息可靠地推送给下游下游消费后调用库存接口。这种最终一致性方案不锁资源吞吐量高实现起来也没有那么复杂。任何分布式事务方案核心都是“隔离性”和“可用性”的二选一。如果业务模型本身能避免跨库写事务最强的事务优化就是不发起事务。比如把一次下单涉及的所有表都放在同一个分片上就能退化成单机事务或者干脆把商品、库存、购物车这些强关联数据在拆分时放到同一个分组节点上。4.3 跨分片关联查询的几种应对思路join 在分库分表场景下大多是反模式。遇到跨分片关联常见替代方案有三个方向冗余把关联查询需要的字段冗余到主表中。比如订单表冗余用户姓名就不需要再 join 用户表。绑定表让需要 join 的两张表用同一个分片键拆分join 在分片内完成。汇总层把订单、支付、退换货等事件数据同步到检索系统或宽表存储由汇总层统一承担复杂查询和报表需求。这几个方案里冗余字段最直接但要注意一致性。用户改名之后订单表里的冗余姓名可能还是旧的。如果业务能接受短时间不一致比如延迟一分钟以内那完全可行。汇总层则是目前比较主流的方向尤其报表类需求。数据实时性要求不高的话可以每天离线同步要求实时的话就用消息队列实时写一份宽表。5. 分库分表的实战思考分片键怎么选、数据迁移怎么做、什么时候不适合拆5.1 分片键的选择标准不是“唯一”而是“高频和均匀”分片键最自然是主键但主键只解决了唯一性问题没有解决“查询是否高频”的问题。比如订单表主键是 order_id但业务里绝大多数查询都按 user_id 查那把主键当分片键查询场景就全变全分片扫描。优先选高频查询字段通常是用户维度。如果有的场景按商家维度查有的按用户维度查尽量做两套数据或做二级索引映射。分片键还需要保证数据均匀。取模方式下如果业务上某个大客户贡献了 30% 的数据量那对应分片一定先达到容量瓶颈其他分片却是闲置的。这时可以考虑按哈希值取模或者把超大客户单独拎出来做规则分片而不是硬套一个全局规则。分片键选好后尽量别改。改分片键意味着分片数据重新分布、双写、回填、灰度切流整个工程量非常大。真实场景里很多分库分表项目翻车不是因为拆分方案有问题而是分片键选错导致查询覆盖率太低上线后性能不是提升反而是下降。5.2 数据迁移与双写别想着一次性切换分成新的分片表之后历史数据要迁移到新表业务流量要逐步切换。常见的流程是先把旧表全量导入新表。从之前某个时间点开始开启双写业务同时写旧表和新表。用补偿任务把全量导入开始之后累积的增量数据再搬运一遍。对比新旧数据用抽样校验和总数校验跑一遍。读流量逐步切到新表先切部分白名单再放量。观察延迟、错误率、分片负载是否均衡确认稳定后关闭双写。双写期间要重点处理两个问题写新表失败但写旧表成功不能影响主流程补偿任务要保证幂等否则重复搬数据会把数据弄脏。5.3 有些情况宁可先扩容也不要急着拆分库分表是复杂度非常高的改动不是数据量一大就一定要拆。如果单表几百万行、查询时间还好连接数也没被打满那先用缓存扛读压力或者做一主多从的读写分离会更划算。分库分表的硬性触发条件一般是单表数据量持续增长且索引性能明显退化或单实例连接数长期紧张或磁盘容量无法通过扩容解决。即便是要拆也建议从最小范围开始比如只拆最热的订单表其他表保持原样。一次性把全库所有大表拆完表面上很完整实际上开发和运维的负担会倍增每一条查询都要重新评估是否走了正确分片。6. 我在实际使用中的几个体会用了几年分库分表中间件发现最大的问题不是原理复杂而是很多人把分库分表当成银弹。中间件确实能让你像操作一张表一样操作多个分片但它在底层也只是把一条 SQL 复制成多条再合并返回。真正的思维瓶颈在于是否理解数据分布带来的全局约束。单条记录的查询还能通过索引快速定位但范围查询、排序分页、统计聚合、跨节点事务每一个都相当于在分布式系统里做全局协调复杂度不会凭空消失。所以好的架构不是把所有数据都拆得稀碎而是尽量让绝大部分请求只访问一个分片核心操作退化成单机事务只有极少数跨分片场景走中间件的合并能力。另外建议团队在引入分库分表中间件的同时把数据迁移、分片键登记、全分片扫描治理这些配套机制搭起来。后面维护的时候你会发现真正限制你的不是 SQL 能写多复杂而是你没有一套可靠的工具去回答“数据现在在哪儿、应该去哪儿、找不到了怎么办”。把这套基础设施建好分库分表才能从“拆得快”变成“用得稳”。