日期：2026-07-11
难度：中等
标签：#面试 #MySQL #分库分表 #分布式系统 #VIP
一句话答案
分库分表把单机问题转化为分布式问题，会带来路由、跨分片查询、事务、唯一 ID、分页排序、扩容迁移、热点和运维一致性等复杂度。
面试口语版
拆分后最直接的问题是原来一次 SQL 能完成的 JOIN、聚合、排序和分页可能要在多个分片执行，再由应用合并，性能和正确性都更难保证。跨库事务不能再依赖单机 ACID，通常要通过业务拆分、消息最终一致、TCC 或 Saga 处理；自增 ID 也要换成全局唯一方案。另外分片键选择不当会造成热点或大量广播查询，扩容时还要迁移和重路由数据。运维层面则增加连接数、监控、备份恢复、DDL、故障定位和数据对账成本。
原理拆解
| 问题 | 典型表现 | 常用处理 |
|---|---|---|
| 跨分片查询 | JOIN、聚合、排序成本高 | 冗余、宽表、ES、应用聚合 |
| 分布式事务 | 局部成功、局部失败 | 最终一致、事务消息、补偿 |
| 全局 ID | 自增冲突 | 雪花、号段、全局序列 |
| 分页 | 各分片都要取数再归并 | 游标分页、限制深翻页 |
| 扩容 | 哈希重映射与双份数据 | 预分片、双写迁移、灰度 |
| 热点 | 单租户或热点键压垮分片 | 散列、热点拆分、限流 |
关键细节
- “拆得越多越好”是错误的，分片数量会直接放大连接和运维成本。
- 逻辑主键、唯一约束只能在单分片内天然保证；全局唯一需额外设计。
- 数据倾斜既可能来自数量，也可能来自少量热点数据的访问频率。
面试官追问
- 分库分表后如何做跨库分页？
- 如何保证全局唯一约束？
- 分片键选错后如何补救？
高分补充
分库分表是“用系统复杂度换容量和吞吐”，只有收益超过长期研发、迁移和运维成本才值得实施。
学习清单
- 从查询、事务、ID、扩容、运维五类问题组织回答。
维护与整理 · Yihui在 GitHub 上编辑