分库分表是为解决单库单表数据量大、并发高、性能瓶颈等问题，触发条件包括单表超500万行或2GB、写入超2000QPS、响应延迟超200ms且优化无效、存在天然隔离维度；关键在合理选分片键，需高频查询依赖、分布离散、语义稳定；落地需应对全局ID、跨库分页、JOIN、分布式事务等挑战，并重视平滑迁移、中间件选型、元数据治理与扩容预留。
分库分表是为了解决单库单表数据量过大、并发压力高、性能瓶颈等问题，面试中常考察你对业务场景的理解、分片策略的选择依据、以及落地时的关键权衡点。不是单纯背概念，而是看你能不能结合实际做合理设计。
明确分库分表的触发条件
不能一上来就分，要先看是否真有必要。常见判断依据包括：
- 单表数据量超过 500 万行 或容量超 2GB，且查询明显变慢（尤其带非索引字段排序/分页）
- 日均写入峰值持续超过 2000 QPS，主库 CPU/IO 长期高于 70%
- 核心接口平均响应时间因数据库上涨超 200ms，且优化索引、读写分离后无明显改善
- 业务存在天然隔离维度（如多租户、按地域运营），适合水平拆分降低耦合
选对分片键（Sharding Key）是设计成败关键
它决定了数据怎么切、SQL 怎么路由、跨片操作多不多。理想分片键应满足：
-
高频查询都带该字段：比如订单表用
user_id，90% 的查单、查历史都依赖它 -
分布足够离散：避免热点，如用
order_no（含时间戳+随机段）比纯时间字段更均衡 - 业务语义稳定：不随业务逻辑频繁变更，比如不用“所属运营组”这种可能调整的字段
- 尽量避开需要跨片 JOIN 或聚合的场景：若常按
shop_id查销量汇总，又按user_id查行为，就得评估是否引入冗余或异步宽表
分库分表后绕不开的典型问题与应对思路
面试官常追问“你分完之后怎么保证正确性？怎么查？”重点看你的工程意识：
- 全局唯一 ID：不用自增主键。推荐号段模式（如 TinyID）、雪花算法（注意时钟回拨）、或数据库号段表（加缓存减少 DB 查询）
-
跨库分页：避免
OFFSET深翻。改用“游标分页”（记录上一页最大 ID / 时间戳），或在应用层合并后内存排序（仅限小页） - 跨库 JOIN：优先重构为两次单库查询 + 应用层关联；或用 ETL 同步构建宽表；强一致要求高的场景考虑是否真的需要分
- 分布式事务：尽量用最终一致性（MQ+本地事务表）。Seata 等框架可兜底，但别默认选 AT 模式——它依赖数据库代理和全局锁，复杂度高
别忽略平滑迁移和治理成本
很多方案失败不在设计，而在落地。面试中提到这些会加分：
- 迁移分两步：先双写（新老库同时写），再校验+切读，最后下线旧路径
- 中间件选型要看团队能力：ShardingSphere 功能全但配置复杂；MyCat 已趋于维护停滞；自研需评估长期投入
- 必须配套建设：分片元数据管理（哪个库表对应哪段数据）、慢 SQL 跨片追踪、分片键监控（识别倾斜）
- 预留扩容路径：比如用 4 库 16 表起步，支持后续扩到 8 库 32 表，规则保持兼容
