MySQL运维避坑指南：17年老兵总结5大经典陷阱

　　去年一月，凌晨三点十七分，监控告警炸了，主库 CPU 98%，连接池打满，应用全挂，但慢查询日志里压根没几条——我盯着屏幕，手还在摸键盘，人已经懵了。

文章配图，仅供参考

　　空调外机嗡嗡响，楼下一整排路灯刚灭，隔壁便利店卷帘门哗啦一下落下来。（上周三修过三次打印机，墨盒卡住两次）

　　我盯住 Threads_connected 值——398，稳定得像焊死的；再盯 Threads_running，27；再盯 Innodb_row_lock_waits，120万次——它昨天还是0。这时候老王叼着烟进来，说：“你看看 max_connections 设多少？”我头也没抬：“600，够用三年。”他吐口烟：“哦，那设成601试试？”我愣了两秒，敲回车执行 SET GLOBAL max_connections=601；然后立刻 SET GLOBAL max_connections=600。再刷一眼 Threads_connected——397。又试一次：601→600，变成395。我手指发凉，手心全是汗，但嘴还硬：“这不扯淡么？改个数字能解锁？”

　　可它真解了。不是缓解，是当场退潮——CPU掉到41%，连接池五分钟内回落到92个，应用页面恢复响应。我调出 SHOW VARIABLES LIKE 'max_connections';，和 SHOW STATUS LIKE 'Threads_connected'; 并排贴在屏幕上，看它们像两个对不上的齿轮，咔咔咬合又打滑。运维手册第十二章第三小节写得清清楚楚：“该变量动态生效，仅影响新连接”。但它没写——当 max_connections 被设为刚好卡死在临界值时（比如当前连接数=599，而 max_connections=600），InnoDB 的线程等待队列会因一个未公开的 hash 表扩容机制卡死——不是锁表，是锁排队逻辑。我们叫它“伪死锁阈值效应”，没人报过 Bug，Oracle 也不认，但去年十一月补丁日志里有一行：“Fix mutex contention during connection limit evaluation”。

　　反正没人敢提“阈值”俩字，怕背锅。甲方刘工当时就站我背后，全程没说话，直到我调完参，他掏出保温杯喝一口，说：“你们定制度，我们照着干，出事，是你们的事儿。”我没接话。他杯子底下垫着张便签，印着“XX云数据库白皮书（2023版）”，边角都磨毛了。

　　我也不知道这算不算坑——它不像死锁那么闹腾，也不像主从断开那么明显；它就蹲在那儿，等你某天把 max_connections 设得特别“刚好”，等你在凌晨三点十七分刷新了第十七次 show processlist，等你忽然发现那个连接数始终差1才到上限——就像超市收银台永远排在你前面那位，结账动作特别慢，可她确实只买了三样东西。（我抽屉第二格有半包没拆的薄荷糖）

　　后来我们改了巡检脚本，加了一行判断：如果 Threads_connected > (max_connections × 0.95) 且 innodb_row_lock_waits 暴涨，就自动 bump +1 再回设。没人敢写进规范文档。因为写进去，等于承认我们天天绕着一个不修的漏洞跳舞。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

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