一张大表要怎么安全地加字段/分库分表?

后端开发第 12 / 13 题答题框架
参考思路:加字段(MySQL 8 即时加列/低峰期/gh-ost)→分表垂直水平→分片键选择→跨分片查询与全局 ID 的代价。强调渐进式迁移。

五个经典回答示范

回答一 · 校招应届版

先说加字段:MySQL 8 支持瞬时加列基本无感;低版本大表要用 gh-ost 或 pt-osc 在线改表,原理是建影子表加触发器或 binlog 回放增量再原子切换。分表分两类:垂直按业务拆库,水平按分片键拆行;分片键通常选查询最高频的维度比如用户 ID,用哈希或范围分片。

回答二 · 1-3年经验版

我经历过订单表 20 亿行的水平拆分。方案:按用户 ID 取模 64 分片,保证单用户订单在同一分片;全局订单号内嵌分片位解决无分片键查询的路由;跨分片查询走异构的 ES 和数仓,不在 OLTP 上做聚合。迁移过程双写加数据校验加灰度切读,回滚预案保留两周。最重要的心得:分片键设计错了后面全盘皆输。

回答三 · 资深版

我会先评估要不要拆:单表行数只是参考,写入瓶颈、单机容量、备份恢复时长才是决策依据;能垂直拆、冷热归档解决的就不上水平分片。上了分片就要直面代价:分布式 ID、跨片事务、扩容再平衡、运维复杂度。中间件选型自研代理还是客户端组件看团队。分片是买容量卖复杂度,先算账再动手。

回答四 · 追问应对

追问『分片后怎么扩容』:一致性哈希减少迁移,或成倍扩容只迁移一半数据,双写窗口加校验;『跨分片事务』:尽量避免,必须时用最终一致补偿或按分片串行;『全局唯一 ID』:号段模式或雪花,注意时钟回拨处理;『无分片键的查询』:异构索引表或走检索层,禁止全分片广播大查询。

回答五 · 反面示范

『表大了就按时间每月分一张表,查询的时候 union all 起来,或者干脆分库分表一步到位,拆一百个库肯定够用。』——点评:按时间分表只适合归档型时间线查询,跨月查询和分页会很难受;拆一百个库是拍脑袋——没有容量测算和分片键设计,跨片查询和扩容问题一个没考虑。

怎么练这道题
  1. 打开 模拟练习,选择「后端开发」方向,限时 3 分钟作答本题。
  2. 对照上方答题框架,逐点检查:哪些要素没覆盖、哪里表达啰嗦。
  3. 用自己项目的真实经历替换框架中的占位内容,重讲一遍并录音回听。

这类题在真实面试中常被追问细节,
建议进入限时模式练一遍。

开始限时演练