DBA熬夜改表？这本MySQL手册让设计运维一步到位

　　跟 DBA 吵。

　　去年冬天，凌晨两点十七分，运维群弹出第十九条告警，我盯着那行 ALTER TABLE `order_detail` MODIFY COLUMN `sku_id` BIGINT UNSIGNED NOT NULL，手抖着把咖啡杯搁在监控大屏支架上——杯底印的公司 logo 正好卡在 CPU 使用率曲线峰值下面，歪得让人想伸手去扶。DBA 老张语音里带着鼻音：“加索引我能加，改列类型？你让应用先扛住空值崩三分钟再说。” 我说：“这表去年双十二就该改，现在连灰度开关都没推完，前端小王昨天还问我能不能把 sku_id 当字符串传——他连 binlog 过滤都配错了三次。”

　　我原以为改列是语法层面的事，结果第一次 exec 后主库 IO 陡增四十秒，从监控大屏右下角飘出的“磁盘队列深度”曲线突然抖了一下，像被谁用指甲掐了下。没人说话。PM 小林在群里发了个“？”然后撤回，三分钟后又发了个“我这就叫测试压测”，再没后续。测试老周那会儿正蹲在工位底下接网线，我看见他脚踝上袜子滑下来一截，露出点青筋，挺突兀。

　　DBA熬夜改表？这本MySQL手册让设计运维一步到位。我说这话时自己都笑了——不是不信，是信得太晚。手册里第三章那个“类型变更兼容性矩阵”，列了二十三种组合，每种底下标了“可热改”“需停写”“建议重建”，字小得要凑近看，但真翻过两遍的人，不会再在上线前五分钟才问“TEXT 改 MEDIUMTEXT 算不算 DDL 锁表”。我敢打包票：它把“能不做”的事儿，全用红框标死了。比我们当年靠经验猜强多了。

　　比如 rename column 那节，没讲原理，直接甩三行 shell 脚本——第一行检查旧字段是否被触发器引用，第二行查应用代码里有没有硬编码字段名（它真写了怎么 grep），第三行才执行 rename。我试过，第二行 grep 出来八处，其中五处是 test 文件夹下的 mock 数据，两处是已下线接口的注释，只剩一处真在跑。但就这一处，我们花了六小时改。而手册里只写了句：“若 grep 出非废弃路径，请暂停此处阅读，立即 call PM。”——不是建议，是命令式语气。我就照做了，PM 小林当场把需求评审纪要发我邮箱，带附件和修改时间戳，她连茶水间倒水的工夫都没耽误，回来时手里那杯热水还冒着白气。

文章配图，仅供参考

　　oncall 手机震了一下。震动声特别短，像被人摁住半秒就松开。我瞥了眼锁屏，是值班系统推送的：“备库延迟超阈值”，后面跟了个黄色感叹号。我顺手关了，没点开。这事跟改表没关系，但它就是发生了，发生在我说“优胜劣汰”的第三秒。人就是会被这种事打断节奏，就像我们永远记不清到底哪次发版，是因为中间件版本号写错一位、还是 because 开头的条件判断少了一个括号，最后导致订单号生成重复。反正那次回滚之后，DBA 老张请我在楼下便利店买了两罐啤酒，易拉罐拉环崩开的声响，在冬夜特别脆。

　　其实手册里没提 KPI。但我知道组里有人偷偷把“单月 Schema 变更失败率”设成个人 OKR 项，还藏在子目标第三层。我不知道该夸他还是替他捏把汗。KPI 是个好东西，只要你别把它当尺子量别人的命——比如我们组上季度有两个人因为线上 ddl 没测全，绩效面谈时被问“对技术债的理解”，一个人答了十四分钟，另一个人说了句“我明天去把 schema diff 工具链补完”，就被放过了。这事儿跟手册无关，但我每次翻到目录页那个“附录E：变更检查清单模板”，都会想到他俩。

　　有个失败案例，我必须说。去年十一月，我们上线一个库存分库策略，提前两周照手册第五章做了“跨分片 JOIN 模拟验证”，测出来一切正常。结果真正切流那天晚上，一个慢查报警持续十八毫秒——不是 QPS 崩了，是某条 UPDATE 在二级索引回表时多走了三层 B+ 树。原因呢？手册没写错，但我们忽略了 MySQL 8.0.29 的 optimizer_trace 有个 bug，会在 index merge 场景下把 key_len 算偏三个字节，导致实际选错了索引。这不是手册的锅，是它的边界——它不兜底版本缺陷，也不替你盯 patch note。这点它写得很老实：“本文档基于 8.0.33，低于此版本请自查 release notes”。我原以为这种话是套话，结果真踩上了。

　　所以现在我见新人，不先教他们怎么写 pt-online-schema-change，而是让他们翻手册第七章开头那段话：“Schema 设计不是一次动作，是三次妥协：向历史代码妥协，向未来扩展妥协，向 DBA 的睡眠质量妥协。” 写在纸上很轻，落到地上全是响动。上周三我又看见老张在茶水间煮挂面，电饭煲盖子没盖严，水汽糊了整块玻璃，他拿纸巾擦的时候，我顺手把他手机屏幕朝下扣在台面上——上面正亮着微信对话框，最后一句是：“明早九点上线，我守着。”

　　手册我不推荐给所有 DBA。有些人的经验足够绕过手册里七成内容；有些人则还没被锁表锁到凌晨三点过，看不懂“建议预估影响范围时，先数一数主键上的外键数量，再数一数应用日志里 daily_error_pattern 出现频次”。我自己是后者。所以我打算下周起，把手册第一页复印下来贴在显示器边框上，就贴在咖啡渍旁边。如果哪天我忘了，就让它提醒我——别再让改表，变成一场需要运气的赌局。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!