在PHP后端待久了几乎都会遇到同一个坎业务还没死数据库先扛不住了。我刚接手某商城系统那会儿订单表接近八千万行一个普通的分页查询走到三四秒每天凌晨的统计任务能把主库CPU打到80%以上。当时团队商量下来结论很一致——单表单库已经到极限了得上分库分表。分库分表这四个字很多PHP开发者一听就头疼。它不像加索引、搞读写分离那么简单一旦拆了所有SQL、事务、分页、统计全都得跟着改。但说实话只要理解了它到底在解决什么问题、拆完会带来哪些连锁反应这件事完全是可以掌控的。这篇文章我按自己的实操经验把分库分表从设计到落地的复杂问题逐一拆开讲包括分片键怎么选、全局ID怎么做、历史数据怎么迁、跨库查询怎么兜住以及扩容和数据倾斜这些长期麻烦。如果你正在做PHP项目数据库单表数据量已经大到影响业务或者公司准备做中台化改造又或者你只是想把分库分表的全貌提前搞清楚这篇都适合你。我会尽量用说人话的方式把里面绕不开的坑和能直接抄作业的方案都写出来。1. 先搞懂什么时候才需要分库分表分的是什么1.1 不是性能一慢就拆很多团队容易走进一个误区线上有个慢查询Leader一拍脑袋说“分库分表吧”。这是个非常危险的决定。拆库拆表意味着所有写入路径、查询路径、报表统计、数据同步都要重构代价极大所以必须确认当前瓶颈真的是“数据量和吞吐量”问题而不是SQL本身写得差。我一般看三个信号。第一是单表数据量InnoDB的B树在数据量超过一定量级后索引层数变高回表成本增大通常单表到两千万行以上就会出现明显的性能拐点当然这跟行宽、索引设计有关系但可以作为参考。第二是单库的连接数和IO连接数长期打满或者磁盘IOPS持续高位即使读多写少也已经吃紧。第三是慢查询比例排除掉缺少索引、笛卡尔积、大事务这些低级问题之后慢查询依然随数据量线性增长那才真是容量问题。打个比方小区快递柜满了住户取件排队。你可以先优化取件流程、多设几个柜门这叫优化SQL和加索引也可以在门口按楼栋分几个投递点把包裹分流这才叫分库分表。分库分表是对“容器容量”下手不是对“取件流程”下手。我当时的判断标准很简单单表超过两千万行且每日新增超过一百万行哪怕索引建得再合理也会有顶不住的一天。只要满足这两个条件我才会认真做分库分表方案。1.2 分库、分表、垂直、水平一次讲清楚很多人容易把分库和分表混着说其实它们治的是两个病。分库解决的是连接数和吞吐量问题。一个数据库实例的连接数、磁盘IO能力有上限把所有表放在一个库里再快也会碰到实例天花板。拆成多个库之后请求可以分散到不同实例上整体吞吐就上去了。分表解决的是单表数据量问题。一张表两千万行和一张表两百万行索引扫描成本完全不同。拆成多张结构一样、数据按规则分散的表每张表的数据量降下来查询自然快。再搭配垂直和水平这两个维度看就更清晰了垂直拆分按业务域拆表或拆库。比如把订单、用户、商品三个模块拆到不同库表结构完全不同。解决的是模块间相互影响、单一库压力过大的问题。水平拆分把同一张表的数据按某个字段散到多张表或多个库中。比如订单表按user_id拆成64张表每张表结构完全相同数据量只有原来的1/64。实际项目中两个维度经常一起用。我见过的最多的情况是先垂直拆分成订单库、用户库、商品库再对订单库做水平分表。这样每个核心库的容量都能独立扩展某一张表爆了也不会拖垮整个业务。但这里必须提前说一句分库分表不是没有代价的。拆完之后跨库JOIN做不了了事务范围变小了全局唯一ID不能靠自增了分页排序要重新设计。这些复杂问题才是这篇真正要讲清楚的东西别把代价想小了。2. 分片键与分片策略设计错了后面全是坑2.1 分片键怎么选分库分表的第一步永远是选分片键不是选数据库中间件。分片键决定了数据分布到哪张表、哪个库所有查询能否命中分片都取决于它在不在查询条件里。我选分片键只看三个原则。第一必须是业务里的核心查询维度比如订单系统查得最多的是“某个用户的订单列表”那user_id就是天然的分片键商户后台查最多的是“某个商户的订单列表”那merchant_id更合适。第二分布要均匀如果某些值的数据量特别大就会出现热点分片这个后面单独讲。第三尽量不可变分片键一旦可以修改意味着数据要跨库跨表搬迁这在生产环境是灾难。举一个实际例子。某商城系统的订单表高频查询有两种用户在个人中心查自己的订单运营后台查某个时间段的全部订单。如果以user_id作为分片键用户查询可以完美命中单表但运营按时间范围查就需要扫全部分片。如果以order_id作为分片键数据分布更均匀但用户列表查询就麻烦了。权衡之后我们选了user_id做分片键运营后台的跨分片查询不去硬查而是把订单数据异步同步到搜索平台所有复杂筛选、聚合统计都走搜索平台这样两边都舒服。这个思路很重要分片键只能选一个业务主维度多维度查询用别的存储去兜不要想着让一个分片键满足所有查询。2.2 三种常见分片算法选型确定分片键之后下一步就是按什么规则把数据映射到具体库和表。业界常见的有三种取模/哈希、范围分片、一致性哈希。取模/哈希是最直观的比如user_id % 64结果落在0到63之间对应64张表。优点是数据分散均匀实现很简单PHP代码里一行就能算出来。缺点是扩容很痛苦从64张表扩到128张表时取模结果全部改变大量数据需要重新分布。范围分片比如按用户ID区间或按月份分表。优点是一段时间内的数据集中很适合时序类数据也方便扩容新增一个区间加一张表就行。缺点是容易产生热点比如最近一个月的数据都在最新一张表里访问量集中在那张表上盘片会先于其他表被打爆。一致性哈希是分布式系统里的经典方案数据按哈希值落在环上引入虚拟节点之后扩容时只需要迁移少量数据。优点是扩容平滑缺点是路由实现复杂度高在PHP项目里维护成本不低而且范围查询能力弱。这三者没有绝对的好坏要看场景。我自己的排序是数据量大、需要长期演进的项目优先考虑一致性哈希或带逻辑分片的取模方案简单业务、短期容量可控的直接用取模时序日志类数据用范围分片最省事。2.3 路由规则在PHP里怎么落地路由规则可以放在三个地方数据库中间件、自研的客户端SDK、业务代码里的数据访问层。对大多数PHP团队我不建议一开始就上重中间件可以把路由规则封装在Repository层或Model层用一种“伪中间件”的方式先跑起来。核心思路是先算库号再算表号。假设有4个库、每库16张表分片键是user_id路由代码如下class OrderRepository { private const DB_COUNT 4; private const TABLE_COUNT 16; private function route(int $userId): array { $dbIndex $userId % self::DB_COUNT; // 这样设计是为了让同一个用户的数据落在同一个库内 // 尽量避免同一个用户的订单散落在多个库。 $tableIndex intdiv($userId, self::DB_COUNT) % self::TABLE_COUNT; return [ db $dbIndex, table sprintf(order_%02d, $tableIndex), ]; } public function getUserOrders(int $userId, int $page, int $pageSize): array { $route $this-route($userId); $table $route[table]; // 根据路由结果选择对应的数据库连接 $conn DBFactory::getConnection($route[db]); $offset ($page - 1) * $pageSize; $sql SELECT * FROM {$table} WHERE user_id ? ORDER BY id DESC LIMIT ? OFFSET ?; // 这里用预处理参数绑定 $stmt $conn-prepare($sql); $stmt-execute([$userId, $pageSize, $offset]); return $stmt-fetchAll(); } }路由代码本身不复杂复杂在于约束。所有入口都必须通过这个Repository层业务代码里不允许直接拼表名。上线后如果有人图省事在别的地方绕过路由写了一条全表扫描SQL整个分库分表的意义就没了。另外要强调分片键必须出现在WHERE条件里。如果你按user_id分片查询时没带user_idPHP端根本不知道去哪张表找数据只能全库全表扫这是最要命的性能事故。后面会专门讲怎么兜住这种查询。3. 上了分库分表最先要解决的三件基础工程全局ID、数据迁移、双写3.1 全局唯一ID怎么设计分表之后数据库自增ID就不能用了。原因很简单每张表都从1开始自增多个表插入的数据ID必然重复。如果ID还承担着业务透传功能比如订单号发给用户、传给支付渠道重复就是灾难。常见的替代方案有UUID、雪花算法、号段模式。UUID的优点是生成简单、全局唯一、无需中心节点。缺点也很明显字符串太长无顺序性在InnoDB里作为主键会让索引页频繁分裂写入性能很差。除非主键不是业务主键否则我不建议在核心订单表用UUID。雪花算法Snowflake是很多公司的首选。它把64位ID拆成时间戳、机器ID、序列号三段趋势递增性能高。需要注意时钟回拨问题和机器ID分配PHP里需要自己实现或引入现成库。号段模式是我在PHP项目里用得比较多的一种方案。它的思路是数据库里维护一个ID段表每次取一批ID到内存比如一次取1000个业务进程在内存里从1递增到1000用完了再向数据库申请下一段。这样数据库访问次数很少而且ID是趋势递增的对索引友好。我自己的推荐排序是中小项目用号段模式简单可控大型项目用雪花算法需要做好时钟同步和机器ID管理。不管选哪个都要保证全局唯一否则后面的迁移和双写都没法做。3.2 存量数据迁移全量增量双写从单表迁到分表最怕的不是代码迁移而是历史数据怎么搬到新结构里并且不丢不重。全程我拆成五个阶段设计目标表结构、开启增量双写、全量迁移、数据校验、灰度切换。先做增量双写。在业务代码里所有写入操作同时写旧表和新分片表新写入的数据两边都有。这个阶段旧表还是线上主表新结构慢慢积累数据。双写逻辑要保证幂等比如以订单号作为唯一键重跑任务不会产生重复数据。接着做全量迁移。用脚本分批读取旧表数据按路由规则写入新分片表。这里不要一把梭按ID范围分批处理每批几百条到几千条避免长时间锁表和大事务。数据校验是很多团队容易偷懒的一步但我强烈建议做三层校验。第一层数行数对每个分片表count和旧表对账第二层抽样对比按订单号抽一定比例的数据比对关键字段第三层做增量对比利用binlog或者日志解析校验双写期间的增量数据两边是否一致。最后灰度切换。先让少数流量读新表结构观察性能和正确性确认没问题再逐步把读切过来最后停掉旧表的写保留一段时间的旧表只读备份作为回滚依据。3.3 双写一致性要注意什么双写最核心的问题是两张“纸”上的字可能不一样。旧表写成功了新表写失败怎么办反过来呢有三种常见顺序先写旧表再写新表旧库无风险但新库失败时旧表成功会导致新结构缺数据。先写新表再写旧表新结构优先但旧表失败会影响线上主库。异步双写业务只写旧表通过消息队列把变更同步到新结构。无侵入、解耦但有延迟实时性要求高的场景不合适。我的建议是迁移期用先旧后新的同步双写加补偿任务。正常业务先保证旧主库不挂新表万一写失败补偿任务会根据时间窗口重放增量数据。重点是所有写操作都要有唯一业务键重放不会导致重复。另外一个容易踩的坑历史数据里如果存在很久以前的订单可能没有预留分片键字段比如user_id字段在旧库是NULL。这种情况需要在迁移前做数据清洗把确实无法确定归属的数据放到一个固定分片并在文档里标记清楚。双写不是只写一次而是一个持续过程等到校验通过、灰度完成才能把旧表停掉。这个周期短则几周长则一两个月要有耐心。4. 分库分表之后的查询、分页和事务怎么优雅处理4.1 不带分片键的查询怎么办分片键选了user_id之后所有按user_id查的操作都很快但业务里总有些场景只按order_id查。比如支付渠道回调给你一个订单号你要找到对应的用户。这时候有一个非常实用的技巧让order_id本身包含user_id的信息。我们后来在做订单号生成的时候直接把用户ID的一段拼进订单号里例如订单号前几位是用户ID的散列值。这样拿到order_id就能反解出分片键路由依然成立。如果订单号已经在用、没法改就只能建一张路由映射表order_id到user_id的映射关系。先查映射表拿到user_id再走分片路由。映射表本身不需要分片数据量在可接受范围内单表就够。还有一类查询完全不带分片键也没有索引比如运营后台按商品查订单。别纠结数据库直接让业务走搜索平台或者数仓。我的原则是分片内数据库只服务核心路径查询一切多维分析、模糊检索都以异步同步方式走外部存储。这个思路能帮你省下无数脑细胞。4.2 跨分片查询与聚合的降级策略分库分表后最该戒掉的习惯就是跨库JOIN。不是说做不到而是代价太大多个库的数据散落在不同实例上数据库层无法直接JOIN只能在应用层先把各分片的数据捞出来再拼接网络开销和内存开销都不可控。我见过三种靠谱的降级策略。第一种是应用层聚合。适用于数据量可控的场景比如按分片键并行查询几张分片表然后在PHP内存里做排序、过滤、归并。优点是实现简单缺点是很深的翻页和有总量统计时性能扛不住。第二种是全局冗余表/汇总宽表。比如按user_id分片后再维护一张以merchant_id为分片键的汇总表同步冗余写入。两个高频查询维度都有自己的专用表谁都不打扰谁。代价是写入链路变长存在一致性问题需要异步补偿。第三种是异构存储。把订单数据异步同步到搜索平台或分析型数据库所有运营后台、报表、复杂筛选都在那边查。这是我们最终选择的路也是分库分表大并发场景下沉到一定规模后的通用解法。千万不要想着把所有跨分片查询都靠应用层硬扛当数据量继续增长时应用层聚合也会撑不住。4.3 分页排序如何做到不重不漏分页是最容易被低估的问题。单表分页很简单limit一个offset就完事但分片后第10页的数据可能在第1片和第10片都有你需要从所有分片各取对应的数据再在内存里合并排序后取第10页。当offset很大时比如翻到第1000页每个分片都要取出1000页的数据量性能直接爆炸。针对这个我在项目里一般用两种办法。第一种是禁止深分页改成游标翻页。比如用户订单列表按时间倒序页面往下翻时把当前最后一条订单的ID传回来SQL从WHERE created_at 上次时间开始取而不是LIMIT 10000, 20。游标翻页在分片环境下非常实用因为每一片都只需要取固定数量的下一条数据再归并排序。第二种是用汇总表或者搜索平台的分页能力。既然运营后台的复杂筛选已经走搜索平台了分页自然也在搜索平台做不需要在数据库层实现。如果一定要在数据库层做TopN归并可以用一个小demo展示思路function mergeTopN(array $pageLists, int $limit): array { $merged []; foreach ($pageLists as $list) { foreach ($list as $row) { $merged[] $row; } } usort($merged, fn($a, $b) $b[created_at] $a[created_at]); return array_slice($merged, 0, $limit); }注意这只是一个简化的内存归并。真实场景里每片返回的数据条数要尽可能等于最终需要的条数不要多取否则内存会很快被打满。总数问题也要提前跟业务对齐。分片后精确的count(*)已经没法高效实现了尽量不要直接展示“共X万条”改用“约X万条”或者直接显示当前页大多数用户根本不关心精确总数。4.4 分布式事务能回避就回避分库分表之后原来单库事务里的多个表一旦被拆到不同库本地事务就管不住了。比如下单要扣库存、写订单、减优惠券如果三张表在不同库任何一个失败都可能导致数据不一致。我的第一反应永远是重新设计分片键把需要保证强一致的数据放到同一个库甚至同一张表里。很多情况下是可以做到的。比如订单表和订单明细表都用order_id分片用户下单时主表和明细表天然落在同一个分片事务依然是本地事务。如果实在避不开跨库事务再考虑最终一致性解决方案。我比较推荐本地消息表在同一事务里写业务数据和一条消息记录然后通过一个定时任务扫消息表把消息可靠投递到下一个服务。这个方案不需要额外引入复杂组件PHP项目里用MySQL加一个调度任务就能落地。SAGA长事务也能做但对业务侵入大补偿逻辑复杂。我的观点是别一上来就追求强一致很多业务场景其实能接受最终一致。支付回调这种场景先更新支付状态再异步通知订单系统修改订单状态中间延迟几秒完全可接受。等业务真正无法容忍时再上分布式事务框架否则就是给自己找罪受。5. 扩容和数据倾斜上线之后你还得面对的两个长期麻烦5.1 扩容为什么比最初拆表更难很多团队做完第一次分库分表就松一口气觉得事情结束了。但实际上扩容才是真正的深水区。如果用的是简单的取模分片从4个库扩到8个库时所有数据的路由结果都会变意味着全量数据要重新分布这个过程的复杂度和风险比重建一次分片还高。我建议在初期设计时就给“未来扩容”留好余地。一个非常实用的方案是引入逻辑分片分片键先通过一次取模落到一个逻辑分片号比如总共1024个逻辑分片然后再把逻辑分片映射到物理库和物理表。扩容时只需要调整逻辑分片到物理库的映射关系移动部分逻辑分片的数据业务路由规则基本不用动。举个例子订单表先用user_id对1024取模得到逻辑分片号比如slice_id user_id % 1024再把1024个逻辑分片映射到4个库每库256个分片。扩容到8个库时把其中一些逻辑分片从旧库移动过去就行。因为每个逻辑分片的数据是独立的迁移范围精确可控。一致性哈希也能达到类似效果但逻辑分片映射更容易理解和运维。对PHP团队来说维护一张分片映射表远比在代码里写一套一致性哈希算法要直观。另外一个建议如果预估业务会快速增长一开始的分片数就不要太小。宁可先分64张表只用到8个物理库也不要先分8张表然后马上又得扩。分片数定得多后续扩容的搬迁成本会低很多。5.2 数据倾斜热点分片怎么处理分片键选得好数据分布基本均匀但现实里总有例外。最常见的就是大用户、大商户某些头部用户的订单量是普通用户的上百倍。按user_id分片后这个用户的数据会集中在一个分片那个分片的表增长速度远超其他分片查询也集中在那里形成热点。我发现数据倾斜通常有两个办法排查。第一是定期统计每张分片表的行数画一个分布图偏差超过一定比例就预警。第二是观察各分片的慢查询和QPS某个分片的负载明显高于其他分片大概率就是热点。处理热点我一般分三种情况如果是某个大用户可以考虑把它单独路由到独立分片比如检测到user_id落在热点名单里直接用另一个路由规则跳到专属库。相当于给这个用户开了专柜。如果热点不是单用户而是时段性流量比如秒杀场景下某个商品或活动瞬时流量极大更好的方案是加缓存和限流而不是不断拆表。如果是数据量膨胀型热点可以对单分片做二次垂直拆分把冷热数据分离历史归档到冷表热数据留在热表。这里有个禁忌不要随意修改分片键。有人觉得“把大用户的数据重新分发一下”就行但一旦修改所有与该用户相关的历史数据都要重新路由迁移代价极大。应该在分片键设计阶段就充分评估业务里是否存在超大客户必要时直接对这类客户使用独立路由。6. 给PHP项目的落地建议与我的踩坑体会聊到这里分库分表的核心技术基本都覆盖了。最后分享几个我这几年在实际项目里积累的经验都是踩过坑才换来的。第一分库分表一定先在纸上做容量评估。我常用的粗略算法是预估三年后的日订单量乘以保留天数算出总数据量除以计划的分片数看看单表是否控制在百万到千万级别。如果单表还是可能超过两千万说明分片数不够提前加。第二路由规则一定要收敛到一处。我们项目早期SQL散落在各个Service层上线分库分表前我花了整整一周把所有订单表操作都收拢到OrderRepository这个过程非常痛苦但如果不做后续一定有人写出不带分片键的查询。第三双写期间唯一键是底线。我们发现对账任务经常重放如果没有订单号唯一键重放一次就多一条脏数据。后来在表结构里加了唯一键重放问题直接消失。第四灰度切换别急。我们第一次灰度只放了5%的流量到新表跑了整整三天才敢继续放大。期间确实发现了一个分片边界算错的bug如果一口气全量切换后果不敢想。最后再分享一个小细节我们上线分库分表后几乎每次季度压测都会发现新的慢查询。如果让我回到最开始我会在分库分表的同时就把监控和慢查询大盘建好每台数据库、每个分片表的行数、QPS、延迟都要可视化。分库分表不是一锤子买卖它是系统容量演进的一个阶段后续的扩容、调优、数据治理都会一直持续。把这个心态放平你就能少踩很多坑。 
长河君 · 2026/10/18 21:21:01 · 阅读 1.2k PHP分库分表实战：从分片键设计到数据迁移的完整指南
在PHP后端待久了几乎都会遇到同一个坎业务还没死数据库先扛不住了。我刚接手某商城系统那会儿订单表接近八千万行一个普通的分页查询走到三四秒每天凌晨的统计任务能把主库CPU打到80%以上。当时团队商量下来结论很一致——单表单库已经到极限了得上分库分表。分库分表这四个字很多PHP开发者一听就头疼。它不像加索引、搞读写分离那么简单一旦拆了所有SQL、事务、分页、统计全都得跟着改。但说实话只要理解了它到底在解决什么问题、拆完会带来哪些连锁反应这件事完全是可以掌控的。这篇文章我按自己的实操经验把分库分表从设计到落地的复杂问题逐一拆开讲包括分片键怎么选、全局ID怎么做、历史数据怎么迁、跨库查询怎么兜住以及扩容和数据倾斜这些长期麻烦。如果你正在做PHP项目数据库单表数据量已经大到影响业务或者公司准备做中台化改造又或者你只是想把分库分表的全貌提前搞清楚这篇都适合你。我会尽量用说人话的方式把里面绕不开的坑和能直接抄作业的方案都写出来。1. 先搞懂什么时候才需要分库分表分的是什么1.1 不是性能一慢就拆很多团队容易走进一个误区线上有个慢查询Leader一拍脑袋说“分库分表吧”。这是个非常危险的决定。拆库拆表意味着所有写入路径、查询路径、报表统计、数据同步都要重构代价极大所以必须确认当前瓶颈真的是“数据量和吞吐量”问题而不是SQL本身写得差。我一般看三个信号。第一是单表数据量InnoDB的B树在数据量超过一定量级后索引层数变高回表成本增大通常单表到两千万行以上就会出现明显的性能拐点当然这跟行宽、索引设计有关系但可以作为参考。第二是单库的连接数和IO连接数长期打满或者磁盘IOPS持续高位即使读多写少也已经吃紧。第三是慢查询比例排除掉缺少索引、笛卡尔积、大事务这些低级问题之后慢查询依然随数据量线性增长那才真是容量问题。打个比方小区快递柜满了住户取件排队。你可以先优化取件流程、多设几个柜门这叫优化SQL和加索引也可以在门口按楼栋分几个投递点把包裹分流这才叫分库分表。分库分表是对“容器容量”下手不是对“取件流程”下手。我当时的判断标准很简单单表超过两千万行且每日新增超过一百万行哪怕索引建得再合理也会有顶不住的一天。只要满足这两个条件我才会认真做分库分表方案。1.2 分库、分表、垂直、水平一次讲清楚很多人容易把分库和分表混着说其实它们治的是两个病。分库解决的是连接数和吞吐量问题。一个数据库实例的连接数、磁盘IO能力有上限把所有表放在一个库里再快也会碰到实例天花板。拆成多个库之后请求可以分散到不同实例上整体吞吐就上去了。分表解决的是单表数据量问题。一张表两千万行和一张表两百万行索引扫描成本完全不同。拆成多张结构一样、数据按规则分散的表每张表的数据量降下来查询自然快。再搭配垂直和水平这两个维度看就更清晰了垂直拆分按业务域拆表或拆库。比如把订单、用户、商品三个模块拆到不同库表结构完全不同。解决的是模块间相互影响、单一库压力过大的问题。水平拆分把同一张表的数据按某个字段散到多张表或多个库中。比如订单表按user_id拆成64张表每张表结构完全相同数据量只有原来的1/64。实际项目中两个维度经常一起用。我见过的最多的情况是先垂直拆分成订单库、用户库、商品库再对订单库做水平分表。这样每个核心库的容量都能独立扩展某一张表爆了也不会拖垮整个业务。但这里必须提前说一句分库分表不是没有代价的。拆完之后跨库JOIN做不了了事务范围变小了全局唯一ID不能靠自增了分页排序要重新设计。这些复杂问题才是这篇真正要讲清楚的东西别把代价想小了。2. 分片键与分片策略设计错了后面全是坑2.1 分片键怎么选分库分表的第一步永远是选分片键不是选数据库中间件。分片键决定了数据分布到哪张表、哪个库所有查询能否命中分片都取决于它在不在查询条件里。我选分片键只看三个原则。第一必须是业务里的核心查询维度比如订单系统查得最多的是“某个用户的订单列表”那user_id就是天然的分片键商户后台查最多的是“某个商户的订单列表”那merchant_id更合适。第二分布要均匀如果某些值的数据量特别大就会出现热点分片这个后面单独讲。第三尽量不可变分片键一旦可以修改意味着数据要跨库跨表搬迁这在生产环境是灾难。举一个实际例子。某商城系统的订单表高频查询有两种用户在个人中心查自己的订单运营后台查某个时间段的全部订单。如果以user_id作为分片键用户查询可以完美命中单表但运营按时间范围查就需要扫全部分片。如果以order_id作为分片键数据分布更均匀但用户列表查询就麻烦了。权衡之后我们选了user_id做分片键运营后台的跨分片查询不去硬查而是把订单数据异步同步到搜索平台所有复杂筛选、聚合统计都走搜索平台这样两边都舒服。这个思路很重要分片键只能选一个业务主维度多维度查询用别的存储去兜不要想着让一个分片键满足所有查询。2.2 三种常见分片算法选型确定分片键之后下一步就是按什么规则把数据映射到具体库和表。业界常见的有三种取模/哈希、范围分片、一致性哈希。取模/哈希是最直观的比如user_id % 64结果落在0到63之间对应64张表。优点是数据分散均匀实现很简单PHP代码里一行就能算出来。缺点是扩容很痛苦从64张表扩到128张表时取模结果全部改变大量数据需要重新分布。范围分片比如按用户ID区间或按月份分表。优点是一段时间内的数据集中很适合时序类数据也方便扩容新增一个区间加一张表就行。缺点是容易产生热点比如最近一个月的数据都在最新一张表里访问量集中在那张表上盘片会先于其他表被打爆。一致性哈希是分布式系统里的经典方案数据按哈希值落在环上引入虚拟节点之后扩容时只需要迁移少量数据。优点是扩容平滑缺点是路由实现复杂度高在PHP项目里维护成本不低而且范围查询能力弱。这三者没有绝对的好坏要看场景。我自己的排序是数据量大、需要长期演进的项目优先考虑一致性哈希或带逻辑分片的取模方案简单业务、短期容量可控的直接用取模时序日志类数据用范围分片最省事。2.3 路由规则在PHP里怎么落地路由规则可以放在三个地方数据库中间件、自研的客户端SDK、业务代码里的数据访问层。对大多数PHP团队我不建议一开始就上重中间件可以把路由规则封装在Repository层或Model层用一种“伪中间件”的方式先跑起来。核心思路是先算库号再算表号。假设有4个库、每库16张表分片键是user_id路由代码如下class OrderRepository { private const DB_COUNT 4; private const TABLE_COUNT 16; private function route(int $userId): array { $dbIndex $userId % self::DB_COUNT; // 这样设计是为了让同一个用户的数据落在同一个库内 // 尽量避免同一个用户的订单散落在多个库。 $tableIndex intdiv($userId, self::DB_COUNT) % self::TABLE_COUNT; return [ db $dbIndex, table sprintf(order_%02d, $tableIndex), ]; } public function getUserOrders(int $userId, int $page, int $pageSize): array { $route $this-route($userId); $table $route[table]; // 根据路由结果选择对应的数据库连接 $conn DBFactory::getConnection($route[db]); $offset ($page - 1) * $pageSize; $sql SELECT * FROM {$table} WHERE user_id ? ORDER BY id DESC LIMIT ? OFFSET ?; // 这里用预处理参数绑定 $stmt $conn-prepare($sql); $stmt-execute([$userId, $pageSize, $offset]); return $stmt-fetchAll(); } }路由代码本身不复杂复杂在于约束。所有入口都必须通过这个Repository层业务代码里不允许直接拼表名。上线后如果有人图省事在别的地方绕过路由写了一条全表扫描SQL整个分库分表的意义就没了。另外要强调分片键必须出现在WHERE条件里。如果你按user_id分片查询时没带user_idPHP端根本不知道去哪张表找数据只能全库全表扫这是最要命的性能事故。后面会专门讲怎么兜住这种查询。3. 上了分库分表最先要解决的三件基础工程全局ID、数据迁移、双写3.1 全局唯一ID怎么设计分表之后数据库自增ID就不能用了。原因很简单每张表都从1开始自增多个表插入的数据ID必然重复。如果ID还承担着业务透传功能比如订单号发给用户、传给支付渠道重复就是灾难。常见的替代方案有UUID、雪花算法、号段模式。UUID的优点是生成简单、全局唯一、无需中心节点。缺点也很明显字符串太长无顺序性在InnoDB里作为主键会让索引页频繁分裂写入性能很差。除非主键不是业务主键否则我不建议在核心订单表用UUID。雪花算法Snowflake是很多公司的首选。它把64位ID拆成时间戳、机器ID、序列号三段趋势递增性能高。需要注意时钟回拨问题和机器ID分配PHP里需要自己实现或引入现成库。号段模式是我在PHP项目里用得比较多的一种方案。它的思路是数据库里维护一个ID段表每次取一批ID到内存比如一次取1000个业务进程在内存里从1递增到1000用完了再向数据库申请下一段。这样数据库访问次数很少而且ID是趋势递增的对索引友好。我自己的推荐排序是中小项目用号段模式简单可控大型项目用雪花算法需要做好时钟同步和机器ID管理。不管选哪个都要保证全局唯一否则后面的迁移和双写都没法做。3.2 存量数据迁移全量增量双写从单表迁到分表最怕的不是代码迁移而是历史数据怎么搬到新结构里并且不丢不重。全程我拆成五个阶段设计目标表结构、开启增量双写、全量迁移、数据校验、灰度切换。先做增量双写。在业务代码里所有写入操作同时写旧表和新分片表新写入的数据两边都有。这个阶段旧表还是线上主表新结构慢慢积累数据。双写逻辑要保证幂等比如以订单号作为唯一键重跑任务不会产生重复数据。接着做全量迁移。用脚本分批读取旧表数据按路由规则写入新分片表。这里不要一把梭按ID范围分批处理每批几百条到几千条避免长时间锁表和大事务。数据校验是很多团队容易偷懒的一步但我强烈建议做三层校验。第一层数行数对每个分片表count和旧表对账第二层抽样对比按订单号抽一定比例的数据比对关键字段第三层做增量对比利用binlog或者日志解析校验双写期间的增量数据两边是否一致。最后灰度切换。先让少数流量读新表结构观察性能和正确性确认没问题再逐步把读切过来最后停掉旧表的写保留一段时间的旧表只读备份作为回滚依据。3.3 双写一致性要注意什么双写最核心的问题是两张“纸”上的字可能不一样。旧表写成功了新表写失败怎么办反过来呢有三种常见顺序先写旧表再写新表旧库无风险但新库失败时旧表成功会导致新结构缺数据。先写新表再写旧表新结构优先但旧表失败会影响线上主库。异步双写业务只写旧表通过消息队列把变更同步到新结构。无侵入、解耦但有延迟实时性要求高的场景不合适。我的建议是迁移期用先旧后新的同步双写加补偿任务。正常业务先保证旧主库不挂新表万一写失败补偿任务会根据时间窗口重放增量数据。重点是所有写操作都要有唯一业务键重放不会导致重复。另外一个容易踩的坑历史数据里如果存在很久以前的订单可能没有预留分片键字段比如user_id字段在旧库是NULL。这种情况需要在迁移前做数据清洗把确实无法确定归属的数据放到一个固定分片并在文档里标记清楚。双写不是只写一次而是一个持续过程等到校验通过、灰度完成才能把旧表停掉。这个周期短则几周长则一两个月要有耐心。4. 分库分表之后的查询、分页和事务怎么优雅处理4.1 不带分片键的查询怎么办分片键选了user_id之后所有按user_id查的操作都很快但业务里总有些场景只按order_id查。比如支付渠道回调给你一个订单号你要找到对应的用户。这时候有一个非常实用的技巧让order_id本身包含user_id的信息。我们后来在做订单号生成的时候直接把用户ID的一段拼进订单号里例如订单号前几位是用户ID的散列值。这样拿到order_id就能反解出分片键路由依然成立。如果订单号已经在用、没法改就只能建一张路由映射表order_id到user_id的映射关系。先查映射表拿到user_id再走分片路由。映射表本身不需要分片数据量在可接受范围内单表就够。还有一类查询完全不带分片键也没有索引比如运营后台按商品查订单。别纠结数据库直接让业务走搜索平台或者数仓。我的原则是分片内数据库只服务核心路径查询一切多维分析、模糊检索都以异步同步方式走外部存储。这个思路能帮你省下无数脑细胞。4.2 跨分片查询与聚合的降级策略分库分表后最该戒掉的习惯就是跨库JOIN。不是说做不到而是代价太大多个库的数据散落在不同实例上数据库层无法直接JOIN只能在应用层先把各分片的数据捞出来再拼接网络开销和内存开销都不可控。我见过三种靠谱的降级策略。第一种是应用层聚合。适用于数据量可控的场景比如按分片键并行查询几张分片表然后在PHP内存里做排序、过滤、归并。优点是实现简单缺点是很深的翻页和有总量统计时性能扛不住。第二种是全局冗余表/汇总宽表。比如按user_id分片后再维护一张以merchant_id为分片键的汇总表同步冗余写入。两个高频查询维度都有自己的专用表谁都不打扰谁。代价是写入链路变长存在一致性问题需要异步补偿。第三种是异构存储。把订单数据异步同步到搜索平台或分析型数据库所有运营后台、报表、复杂筛选都在那边查。这是我们最终选择的路也是分库分表大并发场景下沉到一定规模后的通用解法。千万不要想着把所有跨分片查询都靠应用层硬扛当数据量继续增长时应用层聚合也会撑不住。4.3 分页排序如何做到不重不漏分页是最容易被低估的问题。单表分页很简单limit一个offset就完事但分片后第10页的数据可能在第1片和第10片都有你需要从所有分片各取对应的数据再在内存里合并排序后取第10页。当offset很大时比如翻到第1000页每个分片都要取出1000页的数据量性能直接爆炸。针对这个我在项目里一般用两种办法。第一种是禁止深分页改成游标翻页。比如用户订单列表按时间倒序页面往下翻时把当前最后一条订单的ID传回来SQL从WHERE created_at 上次时间开始取而不是LIMIT 10000, 20。游标翻页在分片环境下非常实用因为每一片都只需要取固定数量的下一条数据再归并排序。第二种是用汇总表或者搜索平台的分页能力。既然运营后台的复杂筛选已经走搜索平台了分页自然也在搜索平台做不需要在数据库层实现。如果一定要在数据库层做TopN归并可以用一个小demo展示思路function mergeTopN(array $pageLists, int $limit): array { $merged []; foreach ($pageLists as $list) { foreach ($list as $row) { $merged[] $row; } } usort($merged, fn($a, $b) $b[created_at] $a[created_at]); return array_slice($merged, 0, $limit); }注意这只是一个简化的内存归并。真实场景里每片返回的数据条数要尽可能等于最终需要的条数不要多取否则内存会很快被打满。总数问题也要提前跟业务对齐。分片后精确的count(*)已经没法高效实现了尽量不要直接展示“共X万条”改用“约X万条”或者直接显示当前页大多数用户根本不关心精确总数。4.4 分布式事务能回避就回避分库分表之后原来单库事务里的多个表一旦被拆到不同库本地事务就管不住了。比如下单要扣库存、写订单、减优惠券如果三张表在不同库任何一个失败都可能导致数据不一致。我的第一反应永远是重新设计分片键把需要保证强一致的数据放到同一个库甚至同一张表里。很多情况下是可以做到的。比如订单表和订单明细表都用order_id分片用户下单时主表和明细表天然落在同一个分片事务依然是本地事务。如果实在避不开跨库事务再考虑最终一致性解决方案。我比较推荐本地消息表在同一事务里写业务数据和一条消息记录然后通过一个定时任务扫消息表把消息可靠投递到下一个服务。这个方案不需要额外引入复杂组件PHP项目里用MySQL加一个调度任务就能落地。SAGA长事务也能做但对业务侵入大补偿逻辑复杂。我的观点是别一上来就追求强一致很多业务场景其实能接受最终一致。支付回调这种场景先更新支付状态再异步通知订单系统修改订单状态中间延迟几秒完全可接受。等业务真正无法容忍时再上分布式事务框架否则就是给自己找罪受。5. 扩容和数据倾斜上线之后你还得面对的两个长期麻烦5.1 扩容为什么比最初拆表更难很多团队做完第一次分库分表就松一口气觉得事情结束了。但实际上扩容才是真正的深水区。如果用的是简单的取模分片从4个库扩到8个库时所有数据的路由结果都会变意味着全量数据要重新分布这个过程的复杂度和风险比重建一次分片还高。我建议在初期设计时就给“未来扩容”留好余地。一个非常实用的方案是引入逻辑分片分片键先通过一次取模落到一个逻辑分片号比如总共1024个逻辑分片然后再把逻辑分片映射到物理库和物理表。扩容时只需要调整逻辑分片到物理库的映射关系移动部分逻辑分片的数据业务路由规则基本不用动。举个例子订单表先用user_id对1024取模得到逻辑分片号比如slice_id user_id % 1024再把1024个逻辑分片映射到4个库每库256个分片。扩容到8个库时把其中一些逻辑分片从旧库移动过去就行。因为每个逻辑分片的数据是独立的迁移范围精确可控。一致性哈希也能达到类似效果但逻辑分片映射更容易理解和运维。对PHP团队来说维护一张分片映射表远比在代码里写一套一致性哈希算法要直观。另外一个建议如果预估业务会快速增长一开始的分片数就不要太小。宁可先分64张表只用到8个物理库也不要先分8张表然后马上又得扩。分片数定得多后续扩容的搬迁成本会低很多。5.2 数据倾斜热点分片怎么处理分片键选得好数据分布基本均匀但现实里总有例外。最常见的就是大用户、大商户某些头部用户的订单量是普通用户的上百倍。按user_id分片后这个用户的数据会集中在一个分片那个分片的表增长速度远超其他分片查询也集中在那里形成热点。我发现数据倾斜通常有两个办法排查。第一是定期统计每张分片表的行数画一个分布图偏差超过一定比例就预警。第二是观察各分片的慢查询和QPS某个分片的负载明显高于其他分片大概率就是热点。处理热点我一般分三种情况如果是某个大用户可以考虑把它单独路由到独立分片比如检测到user_id落在热点名单里直接用另一个路由规则跳到专属库。相当于给这个用户开了专柜。如果热点不是单用户而是时段性流量比如秒杀场景下某个商品或活动瞬时流量极大更好的方案是加缓存和限流而不是不断拆表。如果是数据量膨胀型热点可以对单分片做二次垂直拆分把冷热数据分离历史归档到冷表热数据留在热表。这里有个禁忌不要随意修改分片键。有人觉得“把大用户的数据重新分发一下”就行但一旦修改所有与该用户相关的历史数据都要重新路由迁移代价极大。应该在分片键设计阶段就充分评估业务里是否存在超大客户必要时直接对这类客户使用独立路由。6. 给PHP项目的落地建议与我的踩坑体会聊到这里分库分表的核心技术基本都覆盖了。最后分享几个我这几年在实际项目里积累的经验都是踩过坑才换来的。第一分库分表一定先在纸上做容量评估。我常用的粗略算法是预估三年后的日订单量乘以保留天数算出总数据量除以计划的分片数看看单表是否控制在百万到千万级别。如果单表还是可能超过两千万说明分片数不够提前加。第二路由规则一定要收敛到一处。我们项目早期SQL散落在各个Service层上线分库分表前我花了整整一周把所有订单表操作都收拢到OrderRepository这个过程非常痛苦但如果不做后续一定有人写出不带分片键的查询。第三双写期间唯一键是底线。我们发现对账任务经常重放如果没有订单号唯一键重放一次就多一条脏数据。后来在表结构里加了唯一键重放问题直接消失。第四灰度切换别急。我们第一次灰度只放了5%的流量到新表跑了整整三天才敢继续放大。期间确实发现了一个分片边界算错的bug如果一口气全量切换后果不敢想。最后再分享一个小细节我们上线分库分表后几乎每次季度压测都会发现新的慢查询。如果让我回到最开始我会在分库分表的同时就把监控和慢查询大盘建好每台数据库、每个分片表的行数、QPS、延迟都要可视化。分库分表不是一锤子买卖它是系统容量演进的一个阶段后续的扩容、调优、数据治理都会一直持续。把这个心态放平你就能少踩很多坑。