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

　　崩溃那会儿我正蹲在茶水间啃冷包子，手机震第三下才掏出来——甲方发来截图，后台转化率直接跳成零点几，下面一行小字飘着“数据延迟中”。我原以为又是平台抽风，顺手切回数据库监控页，发现连接数卡在997，慢查询暴涨到四百多条，而主库CPU早飙过98%，像台烧红的铁皮 stove。窗外天黑了，办公室空调太冷，我后颈起了一层鸡皮疙瘩。

　　真动手查是凌晨一点半。同事老陈推门进来扔了瓶脉动，说：“你这库再扛两小时，明天晨会得有人去背锅。”我没接话，因为刚看到从昨天下午三点开始，binlog里密密麻麻全是重复的UPDATE语句，同一个用户ID，同一张订单表，被同一条PHP脚本塞了三百多遍。不是SQL注入，不是脏读，是业务侧把重试逻辑写成了“死循环+不校验”。销售小杨昨儿还在群里吼：“客户急要实时数据！”——可他压根没点开过慢日志里的stack trace，只记得催我“重启一下先”。

　　烧了不少。光是临时扩的三台只读从库，加钱加得我支付宝余额当天就见底；RDS自动升配又吞掉一笔，账单明细里写“突发性IOPS尖峰”，我盯着看了两分钟，最后点了“不申诉”。反正平台机制我至今看不懂：为什么一个未加索引的WHERE name LIKE '%张%'能拖垮整个集群？为什么同样一条SQL，在测试环境跑300ms，在生产跑3.6秒？它不说，我就不问。

　　一次账户被搞的复盘。老板坐我对面，保温杯盖都没拧开，直接问：“能不能做到‘别人崩你不动’？”我没答。我原以为只要把缓冲池调大、把连接池管死、把慢查询全干掉，就稳了。结果第三天夜里，新上线的营销活动一推送，连从库都开始抖——原来缓存穿透没压住，Redis挂了之后所有请求直扑MySQL，而我们之前连“二级缓存熔断”的开关都没摸过。老陈那天在工位睡着了，打呼噜声比服务器风扇还响。谁发了张截图？是我自己，凌晨四点随手截的ERROR_LOG，里面一行“Too many connections”后面跟着个时间戳：2024年5月18日 04:17:03，精准得让人想笑。

　　我说“36小时崩溃到稳如磐石”，站得住的地方是优胜劣汰——不是技术优胜，是人。两天半里，前端撕掉三层嵌套的上报埋点，后端砍掉所有“为防丢数据而双重落库”的傻逻辑，DBA组把三个月前定的清理策略真执行了，连产品都学会看explain里那个type=ALL是不是又冒头了。但凡漏掉一环，现在还是在救火。我认了，不是服技术，是服活人堆出来的临界点。就像上周三午饭，隔壁组两个新人为一个索引要不要建争论十分钟，最后端着饭盒去线上验证，回来时碗里米饭都凉透了——那种较真劲儿，比什么参数调优都管用。

　　其实有天早上，我看监控图上QPS曲线终于不再锯齿状弹跳，突然想起我妈前阵子腌酸梅：头三天浮沫翻得吓人，第七天才沉到底，第八天开盖才闻见甜香。MySQL也这样？不一定。但它至少教会我：别信“永远稳定”，信“下次崩得比上次慢一天”。现在我改了习惯——每天下班前强制删掉一个冗余备份任务，每周二中午给主库做次手动FLUSH LOGS，不是怕出事，是提醒自己：系统没呼吸，人得替它喘气。

文章配图，仅供参考

　　手机快没电了，我边充电边翻钉钉，销售小杨刚发来消息：“客户问能不能导三个月数据？”我回了个“等我五分钟”，其实点开了pt-archiver的文档——但没敢真跑。上次删错分区表的事还没彻底平息。今天下午约了跟甲方对齐归档方案，我打算带两页纸过去：一页写清楚哪些数据能导、哪些必须走脱敏脚本，另一页……空着。等他们提出第三个需求时，我再往上填。

（编辑：站长网）

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