PHP架构师私藏调试心法：3行代码秒定90%线上故障

文章配图，仅供参考

　　我抓起键盘敲了仨命令：先`SHOW PROCESSLIST`揪出卡死的会话，再`EXPLAIN`扫了一眼执行计划，最后`KILL`直接干掉。整个过程不超过十秒，慢查询瞬间清零，CPU蹭蹭往下掉。开发在群里发了个“6”，我回了个“这算啥，上次更离谱”——结果话没说完，隔壁工位的小王探头问：“你刚才杀的是不是我的测试连接？”我低头一看，屏幕上的`KILL 12345`，确实是他刚连的会话ID。

　　风扇一直在转，嗡嗡的，吵得人头疼。我盯着屏幕上的行数跳了会儿，突然想起上周跟架构师老张吃饭，他喝多了说漏嘴：“现在线上出问题，别急着翻日志，先看进程里有没有卡住的SQL，十有八九是慢查询。”我当时还笑他太绝对，结果这会儿真被他说中了——那仨命令，不就是他说的“三板斧”吗？

　　后来跟老张聊，他说这招他用了三年，从PHP5.6用到8.1，从单库用到分库分表，就没失手过。我问他为啥这么灵，他叼着烟说：“优胜劣汰啊，能活到线上的SQL，要么是高频核心，要么是低频但关键，剩下的都是垃圾——垃圾就该早点清理，省得拖垮系统。”我琢磨着这话，越想越有道理：那些卡住的慢查询，十有八九是开发手抖写错了，或者测试没覆盖到，真要等到用户反馈，黄花菜都凉了。

　　不过话说回来，这招也不是万能的。上周二下午，主从延迟突然涨到三分钟，业务方在群里狂@我，说订单同步失败。我照例先`SHOW PROCESSLIST`，结果发现从库的`Slave_IO_Running`是`No`，`Slave_SQL_Running`也是`No`。我原以为是网络问题，结果查日志发现，是主库删了张表，从库没同步到，直接卡死了。这时候杀进程没用，得手动`STOP SLAVE`，再`CHANGE MASTER TO`重配，最后`START SLAVE`——整个过程花了二十分钟，业务方差点掀桌子。

　　外卖凉了，我扒拉两口，继续翻日志。这时候老张溜达过来，看了眼屏幕说：“你这情况，下次试试`pt-table-checksum`和`pt-table-sync`，比手动快。”我撇撇嘴：“早说啊，我都手动对半天了。”他笑：“我也是被坑过才学的，上次主从延迟，我手动对表对到凌晨四点，第二天领导问我‘你是不是通宵打游戏了’。”

　　其实这行最坑的，不是技术问题，是沟通。上周五下午，开发说“要改个配置”，我问“影响范围”，他说“就几个接口”。结果改完上线，数据库连接池直接爆了，所有请求卡在`PDO::connect()`。我查了半天，发现是他把`max_connections`从200改成了20，理由是“测试环境够用”。我问他：“测试环境有多少并发？”他说：“也就三五个。”我差点把键盘摔了——线上和测试能一样吗？

　　窗外天黑了，我揉揉眼睛，继续看监控。这时候群里又炸，说“支付接口超时”。我照例先`SHOW PROCESSLIST`，结果发现所有卡住的会话都在等一个`SELECT FROM orders WHERE user_id = ?`——没有索引。我敲了仨命令，杀掉会话，然后在表上加了索引。五分钟后，支付接口恢复正常。开发在群里发了个“谢谢大佬”，我回了个“下次记得加索引”，然后继续盯监控。

　　说到底，老张那“三板斧”能站住脚，靠的就是“优胜劣汰”——线上环境容不得半点垃圾，慢查询、死连接、配置错误，这些都得第一时间清理掉。至于那些更复杂的问题，比如主从延迟、事务冲突、数据不一致，就得靠工具和经验了。不过话说回来，工具再好，也比不上开发自觉——要是他们能少写点烂SQL，我们值班也能轻松点，对吧？

　　下一步我打算把老张的“三板斧”写成脚本，绑定到监控告警上，以后慢查询一爆，自动杀进程、加索引、发通知。不过话说回来，这招也有风险——万一杀的是核心业务连接，或者加的索引影响写入性能，那就麻烦了。所以还得再测试测试，找个折中的方案。至于现在，先盯紧监控，别让慢查询再爆出来就行。

（编辑：站长网）

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