DBA熬夜改表？14年程序员的MySQL实战手册

　　2025年4月，凌晨三点，我盯着监控屏上的MySQL慢查询报警，手机在旁边嗡嗡震动——DBA群里又在@全员：“谁在生产库改表结构？锁了半小时了！”我原以为这又是哪个新人手滑，结果一查日志，好家伙，是市场部要的“实时数据看板”上线，开发直接在主库跑了ALTER TABLE，连索引都没加。

文章配图，仅供参考

　　可锁库有用吗？第二天领导在群里发了个“权重提升方案”，要求所有页面加载时间不超过1.2秒。我点开方案文档，发现里面连“TCP握手耗时”都算进去了，却对MySQL的索引碎片率只字未提。更绝的是，方案末尾写着：“技术部需在一周内完成优化，否则扣季度绩效。”

　　我原以为领导不懂技术，结果下午他把我叫到办公室，指着屏幕说：“你看这个慢查询，为什么不用覆盖索引？”我凑近一看，好家伙，是他自己写的“权重计算SQL”，里面嵌了三层JOIN，还用了GROUP_CONCAT——这SQL要是能走覆盖索引，我直播吃键盘。

　　但我没敢说。因为上周我刚因为“反驳领导”被扣了绩效。那天他说“定时发布功能必须用消息队列”，我解释说“CMS的定时任务本来就有延迟，加队列只会更慢”，结果他拍桌子：“你是领导还是我是领导？”后来我偷偷改了代码，把队列的消费间隔调成了0，结果定时发布还是失败了三次——因为Redis的连接池被打爆了。

　　说到Redis，上周还有个更离谱的事。市场部要搞“白名单用户专属活动”，非让技术把用户ID存进Redis的Set里。我原以为最多也就几万条数据，结果活动上线当天，Set里涌进了三百多万条ID——原来他们把“潜在用户”也加进去了。Redis的内存直接爆掉，所有服务挂了十分钟。DBA老张在群里骂：“谁写的代码？不知道Set的O(N)复杂度吗？”没人敢认，最后是我背了锅。

　　背锅倒也罢了，最恶心的是“劣币驱逐良币”。现在团队里，会写复杂SQL的被骂“不接地气”，懂索引优化的被说“效率太低”，反倒是那些能用“伪原创”生成八百篇垃圾文章、用“权重方案”忽悠领导的“全栈”，升职加薪比谁都快。我原以为技术是靠代码说话，结果发现，在有些地方，技术只是领导的“绩效工具”。

　　就像这次MySQL改表的事。DBA熬夜改结构，开发熬夜修BUG，运营熬夜看数据——可真正该负责的人呢？领导在群里发了个“加油”的表情包，然后继续催“权重提升方案”的进度。我盯着屏幕上的慢查询日志，突然想起上周老张说的话：“这行干久了，你会发现，最累的从来不是技术，是‘解释技术’。”

　　对了，那篇被搬走的“权重提升方案”文档，连错别字都抄了去——比如把“索引碎片率”写成了“索性碎片率”。我原以为搬运的人会改，结果发现他们连改都懒得改。可领导不管这些，他只看“首发”的阅读量——哪怕那阅读量是刷的。

　　现在我在想，要不要把MySQL的慢查询日志导出，做成个“领导专属看板”？就放他办公室的屏幕上，24小时滚动播放。可转念一想，他要是问“为什么这些查询这么慢”，我该怎么回答？说“因为您写的SQL太烂”？还是说“因为市场部要的‘实时数据’太急”？

　　算了，还是继续改代码吧。毕竟，绩效扣了还能再挣，锅背多了……可能就真的背不动了。

（编辑：站长网）

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