分库分表与 ShardingSphere¶
面试追问地图¶
| 主问题 | 必讲关键点 | 下一层追问 |
|---|---|---|
| 分片时机 | 单机瓶颈、容量与吞吐、先治理再拆分 | 垂直拆分与水平拆分 |
| 路由 | 分片键、算法、路由结果 | 无分片键查询与 Hint |
| 表类型 | binding、broadcast、笛卡尔路由 | 广播表一致性 |
| 结果归并 | 遍历、排序、分组、分页 | 深分页与聚合限制 |
| 扩容迁移 | 全量、增量、校验、切流 | 双写、回滚和主键策略 |
一、拆分与路由¶
什么时候需要分库分表？¶
当单库在数据量、写入吞吐、连接数、备份恢复或变更窗口上成为明确瓶颈，且索引、SQL、冷热分离、读写分离和归档已不足以解决时，再考虑分片。分库分表会把 JOIN、事务、唯一约束、分页和运维复杂度交给应用或中间件，不是默认优化手段。
- 垂直拆分：按业务域或表拆库，降低耦合与单库压力。
- 水平拆分：同一逻辑表按分片键分到多个数据节点，提升容量与并行吞吐。
分片路由是怎样完成的？¶
ShardingSphere 解析 SQL，结合逻辑表、分片条件、算法和数据节点生成真实 SQL 并路由。等值、范围、复合键可能使用不同算法；SQL 不含分片键时可能广播到所有分片，吞吐和尾延迟都会恶化。
分片键应满足：高频查询可携带、分布较均匀、值稳定。按用户 ID 分片便于用户维度查询，但按时间范围分析会跨片；按时间分片便于归档，却容易形成最新分片热点。Hint 路由只应服务于无法从 SQL 提取分片值的受控场景。
二、表关系与归并¶
绑定表和广播表有什么区别？¶
- 绑定表：分片规则一致、关联键相同的一组表，例如订单和订单项。声明绑定关系后，关联查询可按相同分片定向执行，避免所有真实表的笛卡尔组合。
- 广播表：每个数据源都有完整副本的小型字典表，查询可在本地关联；写入需要同步到所有副本，因此要关注失败重试和一致性。
跨分片结果如何归并？¶
各分片并行或串行执行后，中间件需要做遍历、排序、分组、聚合或分页归并。ORDER BY ... LIMIT offset, size 可能要求各分片返回 offset + size 条再全局排序，offset 越大，网络和内存成本越高。
优先使用分片键定向查询、游标/seek 分页、预聚合或独立分析系统。不要假设单库可执行的任意 SQL 在分片后仍有相同成本；上线前应核对路由结果和真实 SQL。
三、扩容与迁移¶
扩容迁移如何避免长时间停机？¶
典型流程是：建立新拓扑 → 全量迁移历史数据 → 捕获并回放增量变更 → 校验数量与校验和 → 短暂停写或确保增量追平 → 灰度切流 → 保留回滚窗口。迁移期间必须明确写入唯一来源，随意双写会引入顺序、重试和部分成功问题。
主键不能依赖每个分片各自的自增序列，否则会冲突；可使用号段、雪花类 ID 或业务唯一键，并评估趋势递增造成的热点。扩容不是只改取模数：hash(key) % N 改 N 会搬动大量数据，通常需一致性哈希、虚拟节点或显式映射表控制迁移范围。