MySQL运维设计实战：9年接口人亲历的稳定性跃迁

　　下午三点十七分，监控钉钉弹窗跳出来那会儿我正蹲在茶水间煮挂面——水刚沸，锅盖噗噗顶着响，我伸手去掀，手机震了第三下。

文章配图，仅供参考

　　看是MySQL集群告警：主库CPU 98%，连接数卡在1023不动了，慢查询列表里飘着一条SELECT FROM user_order WHERE status = ? AND created_at > ? ORDER BY id DESC LIMIT 20，后面跟着十七个相同的堆栈，全是从订单导出接口打过来的。

　　我捞了日志，查了应用层调用链，发现这接口半年前改过——把原来按created_at分页改成按id分页，当时还写了灰度方案、压测报告、回滚checklist。但没人动那条WHERE里的status字段索引：它只有(status)，没加created_at，更没覆盖id。我原以为加个联合索引就能收工，结果上线第七天，客服在群里甩截图：Excel导出卡在“正在生成”三十分钟不动，用户投诉订单状态错乱。

　　运维老张蹲我工位边啃桃子：“你那个ORDER BY id DESC，MySQL扫完status=‘paid’的三百二十万行，再排序取前二十？它连内存都懒得申请，直接走磁盘临时表。”他桃核往纸篓一弹，准。

　　我改了索引，建了(status, created_at, id)，跑了ALTER TABLE加字段加索引——八分钟，中间断了两次，第二次重试时我把SQL塞进screen后台跑，转身去厕所，回来发现屏幕卡在“Waiting for table metadata lock”。隔壁组的实习生探头问：“哥，你是不是锁了user_order？”我没理他，扒拉日志，看到凌晨两点四十一分有个人手动执行了UPDATE user_order SET remark = '补单' WHERE order_id = 'xxx'——那条语句没加索引，卡住整张表六十三秒。

　　我也不知道为什么偏偏是那天的补单语句撞上了DDL；反正DDL卡着，导出接口又卡着，告警堆成山。我们后来kill掉那条UPDATE，DDL继续跑，索引建完了，但当天晚上九点，另一个接口突然502——查Nginx access log，全是 upstream timed out (110: Connection timed out) while reading response header from upstream，上游就是刚才那个导出服务。可它的Pod明明还在Running，liveness probe也绿着。

　　（我同事上周换了个IDE主题，浅灰配深蓝，说眼睛舒服；我昨天修了打印机卡纸三次，第三次发现是进纸轮沾了口红印）

　　最后发现是连接池配置被覆盖了：新发版时merge冲突，dev.yml里max-active=20，prod.yml漏了这行，Spring Boot自动fallback到默认值——HikariCP默认是10。十个人同时导出，第十一个请求就卡住等连接释放，卡满三十秒，Nginx判定超时，甩502。而那个“等待连接”的线程，在Jstack里显示WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject，名字叫“HikariPool-1 connection adder”，它就在那儿，不报错、不抛异常、不打印日志，像睡着了一样。

　　我盯着这个线程名看了四十秒。不是因为看不懂，是觉得荒谬——三年前我亲手写的连接池健康检查脚本，去年被运维组统一纳管时删了，理由是“和平台心跳机制重复”。可平台的心跳只管Pod存不存在，不管连接池里有没有十个空闲连接在打呼噜。

　　所以这事到底哪环先崩的？索引没建对？DDL被阻塞？还是那个补单的人不该在生产环境直接update？还是我不该信spring boot的“自动配置”？反正现在order_id字段上已经有三个索引了：PRIMARY、idx_status、idx_status_created_id，而idx_status创建时间是2023年4月，比那次改版早五个月——也就是说，半年前那轮优化，根本没动过这个索引。有人在需求评审里写过“需评估索引失效风险”，这句话现在躺在Confluence第十七页，字体小得要放大两倍才看得清。

　　我关掉终端窗口时，Chrome后台标签页正自动播放短视频：一只柯基犬叼着拖鞋追自己尾巴，循环了第八次。

　　有谁碰到过这个吗：ALTER TABLE加索引期间，UPDATE语句没走索引，卡死DDL，然后下游服务因连接池饥饿产生502，但Jstack里所有线程状态都正常？

（编辑：航空爱好网）

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