如果组长要求你主导项目中的分库分表，大致的实施流程是？

日期：2026-07-11
难度：中等
标签：#面试 #MySQL #分库分表 #场景题 #VIP

一句话答案

先用数据证明单库单表已成瓶颈，再设计分片键和容量模型，完成中间件、ID、一致性与迁移方案，通过全量迁移加增量双写灰度切流，最后校验、回滚演练并持续治理。

面试口语版

我会把实施分成评估、设计、改造、迁移和运营五段。先确认瓶颈是容量、写吞吐还是单表查询，并评估索引、归档、缓存和读写分离能否解决。确定必须拆后，根据核心查询入口选择分片键，计算当前数据量、增长率、分片数和扩容余量，同时设计全局 ID、跨分片查询、事务和路由方案。实施时先做兼容性改造和影子验证，再全量迁移历史数据，通过 binlog 或双写同步增量；灰度读、灰度写并持续做行数、校验和及业务账务核对。稳定后停止旧链路，保留回滚窗口，并补齐监控、扩容和故障演练。

原理拆解

flowchart LR
  A[瓶颈与容量评估] --> B[分片键/分片数设计]
  B --> C[路由、ID、事务改造]
  C --> D[全量迁移]
  D --> E[增量同步/双写]
  E --> F[灰度读写]
  F --> G[校验与正式切换]
  G --> H[监控、扩容、演练]

关键细节

• 分片键优先覆盖最高频查询，既要分布均匀，也要避免跨分片访问。
• 分片数应预留增长空间；直接取模扩容会造成大规模数据重映射，可用预分片或一致性哈希降低成本。
• 双写不能只相信“两个写都成功”，要有幂等、重试、对账和补偿。
• 切流前明确回滚条件；旧库不能过早下线或继续接受无管控写入。

面试官追问

1. 如何选择订单表的分片键？
2. 全量迁移期间如何保证增量不丢？
3. 16 个分片如何平滑扩到 32 个？
4. 如何验证迁移前后数据一致？

高分补充

把成功标准量化为单分片容量、P99 延迟、最大复制积压、允许的数据差异和回滚时限，比只描述技术步骤更像真实项目负责人。

学习清单

• 准备一份订单表从单表迁到 16 分片的完整口述方案。
• 能解释双写、CDC、灰度和对账各自解决什么问题。