数据库分片操作指南：从“单库扛不住”到“分完之后怎么查”

分片不是一个开关，是一段有明确阶段和退出条件的迁移过程。很多团队在“单库写入扛不住”时仓促分片，结果分完之后发现跨分片查询、事务和扩容比单库更棘手。一个可操作的路径应该分四步走。

第一步，先确认分片是不是唯一选项。 在读多写少的场景里，读副本、缓存、查询优化、归档冷数据往往能再撑一到两年。写入瓶颈才更可能需要分片，但也要先排除连接池配置、长事务、热点行更新这些“假写入瓶颈”。一个判断信号是：单表写入 QPS 已经接近单库上限，且业务增长曲线看不到放缓，才进入分片评估。

第二步，选分片键，而不是选分片中间件。 分片键决定了数据分布、查询路由和扩容方式。用户 ID 做分片键，按用户查询天然路由，但按订单号或时间范围查询就要扫全部分片。订单 ID 做分片键，订单查询方便，但用户维度的列表查询变复杂。一个常见折中是选择“查询最频繁且分布均匀”的维度做主分片键，对其他维度建映射表或冗余索引。分片键一旦确定，迁移成本极高，这一步值得花最多时间。

第三步，分阶段迁移，双写加对账。 不要一次性切换。先建新分片集群，开启双写，让新数据同时写入旧库和新库；用历史数据回填工具把存量数据迁过去；然后做全量对账，确认两边一致；再灰度切读，先让少量查询走新库，对比结果；最后切写，旧库降级为只读或备份。每一步都要有回滚路径，双写期间旧库仍然是可信源。

第四步，分完之后重新设计查询。 分片之后，跨分片 join 和聚合查询的成本会显著上升。常见做法是把跨分片查询收敛到应用层：先按分片键路由到单个分片，需要聚合时并行查多个分片再合并；把高频聚合结果预计算成汇总表，按时间窗口更新；对“全量统计”类需求，接受最终一致，用离线任务产出。不要在分片数据库上直接跑跨分片 join，那会把分片的所有收益吃掉。

分片的终点不是“数据分散了”，而是“查询模式跟着分片键重新设计了”。如果分片之后大部分查询仍然要扫全部分片，说明分片键选错了，或者业务本来就不适合分片。分片是最后手段，不是性能问题的默认答案。