分库分表核心目标是解决单库单表数据量过大、性能瓶颈及高并发问题，需结合业务场景合理选择拆分键与策略，并配套分布式ID、跨分片查询处理、分布式事务妥协和扩容方案。
分库分表是为了解决单库单表数据量过大、性能瓶颈和高并发访问问题。面试中考察的不仅是技术实现，更看重你对业务场景的理解、拆分逻辑的合理性，以及对一致性、扩展性、运维复杂度的权衡能力。
明确分库分表的核心目标
不是为了“上技术”而分，而是为了解决具体问题：
- 读写分离扛不住了：主从延迟大、从库压力高、写多读少场景下从库无法分担
- 单表超千万甚至亿级数据：查询变慢、DDL锁表时间长、备份恢复困难
- 单库连接数/IO/CPU打满：比如高峰期QPS突增，数据库成为系统瓶颈
- 业务隔离需求：不同租户、不同区域、不同产品线需要数据物理隔离
区分分库与分表的适用场景
二者常一起用，但逻辑不同，面试时要能说清选择依据：
- 分表（Sharding）：同一库内按规则切分表，解决单表过大问题。适合查询条件固定（如总按 user_id 查）、冷热数据可识别的场景。常见有 range（按时间）、hash（如 user_id % 4）、一致性 hash 等策略
- 分库（Database Sharding）：把数据分布到多个物理库，解决连接数、IO、内存等资源瓶颈。通常配合分表使用，比如“按商户ID哈希分8库，每库再分16张订单表”
- 注意误区：不分库只分表意义有限——单库的连接池、事务、锁、内存压力仍在；不分表只分库则可能造成大量空库或跨库 join 困难
重点讲清拆分键（Sharding Key）的设计逻辑
这是分库分表最核心的决策点，直接决定后续能否高效查询、是否需跨节点操作：
- 选高频查询字段：比如订单系统中，user_id 出现在 90% 的查询条件里，就比 order_no 更适合作为拆分键
- 避免热点：不能选“status=1”这种低基数字段；也不宜选“create_time”导致新数据全写入同一分片（可用“user_id + create_time”组合或加随机后缀缓解）
- 兼顾业务语义：例如 SaaS 多租户系统，tenant_id 是天然拆分键，天然隔离+天然路由，还能支持按租户快速归档或迁移
- 拒绝“万能键”思维：没有银弹。若业务要求既按用户查、又按商品查、还按时间查，就要接受部分场景走异步聚合、ES 辅助或冗余存储
必须提及的关键配套能力
分库分表不是加个中间件就完事，面试官会关注你是否理解落地难点：
- 分布式 ID 生成：不能依赖自增主键，得用 Snowflake、Leaf、UUID+时间戳等方案，确保全局唯一且趋势递增
- 跨分片查询处理：count/group by/order by limit 需中间件（如 ShardingSphere）合并结果；join 尽量避免，必要时用冗余字段、异步同步宽表、或应用层两次查询组装
- 分布式事务妥协：优先用本地消息表+定时校对、Seata AT 模式（需业务表加 undo_log）、或最终一致性设计，不强求强一致
- 扩容方案：预分片（如一开始就设 1024 个逻辑分片，再映射到物理库表）、一致性 hash 动态扩缩容、双写迁移（灰度验证+数据比对）
