分库分表怎么设计？分片键、跨库查询和在线扩容怎么处理？

知识点详解：数据拆开以后，查询和约束怎么办

垂直与水平，拆的是不同维度

假设用户资料和日志由不同模块访问，按职责或字段拆开，是垂直方向；把大量同结构日志按用户或时间分到不同片，是水平方向。

多张表如果仍落在同一台机器，也可能共用 CPU、I/O 和连接限制。分表不等于增加物理资源。

数据库原生分区和应用分库也不是同一运维模型，要明确路由、事务和执行计划由谁管理。

分片键，要从常见查询倒推

假设最常见操作是查看某个用户最近的记录，按用户路由可以减少跨片。但少量超大用户可能形成热点，不能只看平均记录数。

按时间便于归档与范围访问，近期片却可能集中写入。哈希分布较均匀，但范围查询可能遍历多个片。

需要统计访问模式和数据增长，明确不能定位到单片时怎样查询。可变字段当分片键，还会把普通修改变成迁移。

单库里顺手的约束，跨片要重新设计

每片的唯一索引，不自动保证全局唯一。跨片关联和事务也不能直接认为由一个本地事务覆盖。

排行榜或全站分页，要从多个片取候选再合并。深分页会放大扫描和网络成本，排序规则必须有稳定的并列处理，不能各片随便取一段再拼。

必要时可以使用专门的读模型或搜索分析系统，但要说明更新延迟与正确性要求，而不是把复杂查询无条件丢给另一个名字。

迁移不是切路由那一刻才开始

先复制历史数据，再跟踪新增和修改，比较数量及内容，确认增量追平后切换。过程中要控制写入归属，避免旧片和新片产生无法合并的变化。

回退也要设计：切换后新写入的数据怎样保留，旧路由能否读到。只保存旧连接字符串，不等于能无损回退。

验证要用真实查询分布、热点、跨片失败与迁移中的读写，不用“每片少了一半数据”当全部性能证明。

本题机制参考：Azure Sharding Pattern、MySQL 分区限制。

面试官继续追问

为什么不一开始就分很多片？

提前获得扩展空间也会提前承担路由、跨片查询和运维成本，应按需求判断。

读写分离就是分库分表吗？

不是。复制读副本与把不同数据归到不同片，是不同扩展方向。

按用户分片能保证不跨片事务吗？

只有相关数据和操作能按该键落同片时才有帮助，实际边界要逐项检查。

面试速记卡

• 先诊断：容量、写入、读负载与单节点瓶颈。
• 分片键：按查询倒推，兼顾热点和增长。
• 路由：单片定向与多片汇总分开。
• 约束：全局唯一、事务、关联和分页重新设计。
• 迁移：历史复制＋增量追平＋校验＋回退。