DBA熬夜改表？这本MySQL手册让我搞定设计与运维

　　三个月前那晚十一点，我在工位上改完最后一个接口，正准备收拾东西滚蛋，突然收到消息：生产环境订单表挂了。我原以为只是常规的慢查询，结果运维小哥在群里甩了张截图——主库CPU飙到98%，所有写入请求都在排队，像春运火车站的安检口。

　　DBA老张从隔壁工区冲过来，头发乱得像被猫抓过，手里还攥着半块没吃完的煎饼果子。他盯着屏幕看了两秒，突然拍桌子：“谁设计的这表？订单状态和用户ID混在一个索引里？还加了全文检索？”我缩了缩脖子——这表是我三个月前刚入职时接手的，当时觉得“反正现在数据量少，怎么方便怎么来”，现在想想，真是初生牛犊不怕虎。

　　老张一边骂骂咧咧一边打开终端，我凑过去看，发现他没直接改表结构，而是先翻出一本破破烂烂的《MySQL运维手册》，书页边缘都卷起来了，封皮上还沾着咖啡渍。他翻到某一页，指给我看：“看，索引设计三原则——高频查询字段放前面、区分度低的字段放后面、避免冗余索引。你这表，三条全犯。”我盯着那页纸，突然想起上周组会时，他举着这本手册说：“别总依赖我，自己学学。”当时我还觉得他装逼，现在看，人家是真有底气。

　　那晚老张没回家，在机房改表到凌晨三点。我蹲在旁边看，发现他改表的方式很“反直觉”：没直接DROP索引，而是先建新索引，等查询都走新索引后，再删旧索引；没直接改字段类型，而是用pt-online-schema-change工具，避免锁表；甚至还写了段脚本，自动监控慢查询，把超过阈值的SQL抓出来分析。我忍不住问：“这些操作手册里都有？”他头也不抬：“手册里是框架，具体怎么用得靠经验。比如这个pt工具，手册里就提了一句，但实际用起来，参数调不好能把自己坑死。”

　　第二天早上，表终于改完，CPU降到了10%以下。老张把手册扔给我：“拿着，下次别等我熬夜。”我翻开看，发现里面全是手写的笔记——某页边角写着“2021.8.15，某项目因索引设计问题导致主从延迟三小时”，某页中间画了个箭头，指向“分区表慎用，除非数据量超千万”，甚至还有张便签纸，上面写着“记得买咖啡，昨晚又通宵”。

　　后来我仔细读了这本手册，发现它和网上那些“MySQL优化大全”完全不一样。没有长篇大论的理论，全是实操案例：比如“订单表按时间分区后，查询最近三个月的数据变快了，但跨分区查询反而慢了，怎么办？”；比如“某字段从INT改成BIGINT后，存储空间涨了30%，但查询性能没提升，为什么？”；甚至还有“某次误删表后，如何用binlog恢复数据”的详细步骤。这些案例里，有成功的，也有失败的——比如某次因为没测试好新索引，导致线上服务崩溃了十分钟，手册里用红笔标着“血的教训”。

　　我原以为DBA的工作就是“改改表、杀杀进程”，现在才明白，这行最核心的是“预判问题”。老张能熬夜改表而不慌，是因为他见过太多类似的坑，知道每个操作可能带来什么后果。而那本手册，就是他的“经验库”——不是教你怎么做，而是告诉你“这样做可能会踩什么坑，以及怎么避坑”。

文章配图，仅供参考

　　现在我也养成了个习惯：每次改表前，先翻手册，看看有没有类似的案例；改完后，把遇到的问题和解决方案记下来，补到手册里。上个月，我根据手册里的案例，优化了某个慢查询，把响应时间从两秒降到了两百毫秒。老张看了我的笔记，点点头：“嗯，这行就是这样，优胜劣汰——不是工具新旧的淘汰，是经验多寡的淘汰。”

　　对了，那本手册现在放在我工位最显眼的地方，封皮上的咖啡渍更多了。上周新来的实习生问我：“这书这么旧，还有用吗？”我指了指里面密密麻麻的笔记：“有用，而且越旧越有用。”他似懂非懂地点点头，我笑了笑——有些东西，机器学不会，只能靠人传人。

（编辑：站长网）

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