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

　　去年12月那场MySQL崩溃，我现在想起来还后怕——周五晚上十点，增长组的同事突然在群里喊“看板全红了”，我原以为又是哪个埋点又挂了，结果登录服务器一看，主库CPU直接飙到99%，慢查询堆得跟山似的，监控告警短信把手机震得直发烫。运维小哥当时正蹲在机房角落吃泡面，汤溅到键盘上都没顾得上擦，抬头跟我说：“哥，这情况我从业三年没见过。”

　　崩溃的直接原因是个“小优化”——增长组为了赶双十二活动，临时在用户行为表上加了三个索引，说是“提升查询速度”。我翻了下慢查询日志，好家伙，这三个索引直接把写入性能干废了：原本每秒能处理三千条埋点数据，现在连三百都撑不住，数据积压像堵车一样越堆越多，最后把主库活活拖死。运维小哥蹲在地上扒拉泡面盒，突然抬头问我：“哥，你说这索引是不是加反了？”我盯着屏幕上的慢查询，心想这哪是加反了，这是直接把路给挖断了。

文章配图，仅供参考

　　这时候运维总监冲进来，手里攥着手机，脸色比锅底还黑：“大老板问怎么回事，你们谁去解释？”办公室突然安静得能听见空调外机的嗡嗡声，增长组的负责人低头刷手机，假装没听见；运维小哥蹲在角落，继续扒拉那碗早凉透的泡面；我盯着屏幕上的错误日志，突然想起上周五增长组找我“优化查询”时的场景——他们拿着份SQL，说“这个查询要跑十八秒，太慢了”，我扫了眼，发现是全表扫描，随口说了句“加个索引试试”，结果他们直接在生产环境加了三个，连测试都没做。

　　后来我们花了三十六小时抢救：先删掉那三个“致命索引”，再手动清理积压的数据，最后把增长组的查询重写了一遍——原来他们为了算“用户活跃度”，把“登录”和“点击”两个行为混在一个表里查，导致每次查询都要扫全表。我让他们拆成两个表，用UNION ALL合并结果，查询时间从十八秒降到零点二秒。增长组的同事看着新查询的执行计划，张了张嘴，最后说了句：“早这么改不就好了？”我白了他一眼：“早让你们测试，你们说‘时间紧任务重’。”

　　这事儿最讽刺的是，崩溃前一周，增长组还在群里发“战报”——说“通过索引优化，查询效率提升300%”，配图是张监控截图，CPU使用率从20%降到15%。我当时看了眼，心想这哪是优化，这是把隐患埋得更深了。结果现在好了，300%的“提升”换来三十六小时的崩溃，连大老板都惊动了，在晨会上拍桌子：“数据是增长的命根子，你们就这么玩？”

　　现在回头看，这场崩溃的“优胜劣汰”特别明显：增长组为了赶进度，选了个“最省事”的方案——加索引，结果把系统拖垮；我们为了救火，只能选“最笨”的方案——删索引、拆表、重写查询，虽然花的时间长，但至少把根儿治了。运维小哥后来跟我说：“哥，我现在看见‘索引优化’这四个字就哆嗦。”我拍了拍他肩膀：“哆嗦就对了，这说明你长记性了。”

　　上周五增长组又来找我，说“要优化另一个查询”，我直接把电脑推过去：“先写测试用例，跑通了再上生产。”他们愣了下，说“时间紧任务重”，我笑了：“时间紧可以加班，系统崩了可没地方哭。”现在他们写SQL前，会先在测试环境跑三遍，确认没问题才敢提申请——虽然慢了点，但至少不用再经历三十六小时的崩溃了。

　　不过话说回来，这事儿也有我没想到的地方：崩溃那天晚上，运维小哥蹲在机房吃泡面，汤溅到键盘上，结果把某个键给粘住了，后来他修键盘时，发现那个键是“Ctrl”——他说这是“天意”，提醒我们别总想着“Ctrl+C/Ctrl+V”式优化。我听了直乐，心想这小子现在倒会找借口了。但仔细想想，他说得也没错——数据运维哪有什么“捷径”，都是一步一个坑踩出来的。

（编辑：站长网）

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