MySQL运维实战：36小时崩溃到稳如磐石

　　凌晨三点，监控大屏突然开始闪红光，我盯着那串跳动的“MySQL connection timeout”骂了句脏话。桌上外卖盒里的炒粉早凉了，油渍在键盘上凝成块——这已经是近两个月第三次半夜爬起来处理数据库崩溃了。运维群里有人甩了张截图，主库的CPU占用率直接飚到99%，慢查询日志里全是SELECT FROM orders这种要命的语句，我原以为上周刚优化过的索引能撑久点，结果还是被业务方的“临时需求”给冲垮了。

　　第一次崩溃是在周三下午，当时我正在改SEO的TDK标签，浏览器开了三十个标签页，突然收到告警短信，手一抖把咖啡泼在键盘上。冲进机房时，开发组的老王正蹲在服务器前，嘴里叼着根没点的烟，说“可能是并发量突然涨了”。我查慢查询日志，发现有个新上线的促销活动页面，直接在订单表上做了全表扫描，连个WHERE条件都没加——这他妈能不崩？后来业务方说“就临时用两天”，结果用了两周，直到我直接把那个查询的权限给锁了。

　　第二次崩溃更离谱。周五晚上十点，我正在陪媳妇逛超市，手机突然响得像放鞭炮，监控显示从库的复制延迟到了三个小时。超市里噪音大，我蹲在货架后面连VPN，发现是主库的binlog被撑爆了——业务方为了“数据安全”，给每个订单都加了十几个冗余字段，其中还有个256位的加密字符串，导致每条记录的大小翻了三倍。我原以为从库的SSD能扛住，结果复制线程直接被IO压死。最后只能临时把从库换成机械盘，复制速度慢得像蜗牛，但至少没再崩。

　　这两次崩溃后，我做了三件事：第一，把所有慢查询的监控阈值从两秒调到五百毫秒，超过就发钉钉群@相关开发；第二，在主库上装了pt-index-usage，每周跑一次，把三个月没用的索引全删了——有些索引是三年前加的，现在连查询语句都找不到了；第三，跟业务方签了“军令状”：新功能上线前必须先在测试库跑压力测试，超过主库承载能力的直接打回。开发组的老李还跟我吵了一架，说“这样会拖慢上线速度”，我直接把近两个月的崩溃记录甩他脸上：“是拖慢速度重要，还是半夜爬起来修库重要？”

　　第三次崩溃发生在优化后的第三十六小时。那天我特意没设闹钟，结果早上八点被电话吵醒——是业务方的负责人，声音里带着点紧张：“我们刚做了个促销活动，订单量涨了五倍，但数据库没崩！”我迷迷糊糊爬起来查监控，主库CPU占用率稳定在60%左右，慢查询日志里只有零星几条超过阈值的，从库的复制延迟始终控制在十秒内。窗外天亮了，我盯着屏幕发了会儿呆，突然想起上周媳妇问我“你天天加班修库，图啥”，当时没答上来，现在好像有点明白了——优胜劣汰嘛，那些不按规矩来的查询，那些冗余的索引，那些为了“临时需求”乱加的字段，早晚会被淘汰掉，剩下的才是能扛住流量的。

　　当然，这活儿还没完。昨天业务方又提了个新需求，说要在订单表上加个“用户行为分析”字段，我直接回了句“先写SQL优化方案，通过了我再给你们加”。开发组的小张偷偷跟我说：“你最近怎么这么硬气？”我笑了笑没说话——硬气个屁，我就是怕再半夜爬起来修库。对了，昨天我还把机房的噪音分贝测了下，平均72，比之前低了8分贝——可能是优化后服务器没那么拼命转了？

　　现在回头看，这36小时的崩溃像场筛选赛，把该淘汰的淘汰了，剩下的虽然不敢说“稳如磐石”，但至少能扛住常规流量了。至于那些“临时需求”和“数据安全”的借口，我现在只认一条：先证明你的查询能跑进五百毫秒，否则免谈。当然，这话我只敢跟开发说，业务方那边还得哄着——毕竟他们才是给服务器买单的人。

文章配图，仅供参考

（编辑：PHP编程网 - 金华站长网）

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