一、事故现场下午3点运维监控大屏突然变红。[严重告警] MySQL CPU使用率60%[严重告警] MySQL CPU使用率280%[紧急告警] MySQL CPU使用率680%从60%到680%只用了5-10分钟。业务系统开始出现明显卡顿。• 用户反馈页面加载变慢点击无响应• 运维反馈数据库连接堆积慢SQL告警不断• 应用日志大量超时错误线程池打满图1MySQL CPU飙升趋势60% → 680%约10分钟二、排查思路先止血再定位根因这次CPU飙升和普通的慢查询不一样——增长速度太快而且越往后越卡。直觉告诉我这不是单一慢查询的问题。排查原则先止血保命再全面排查最后聚焦根因。图2MySQL CPU飙升排查流程图2.1 第一步止血——确认影响范围① 确认业务影响先判断是全部业务受影响还是部分接口# 查看当前连接数mysql -e SHOW STATUS LIKE Threads_connected;------------------------| Variable_name | Value |------------------------| Threads_connected | 487 | -- 正常值应该在50-100左右------------------------② 查看是否有大量慢查询# 查看慢查询数量mysql -e SHOW GLOBAL STATUS LIKE Slow_queries;----------------------| Variable_name | Value |----------------------| Slow_queries | 1247 | -- 异常偏高----------------------图3慢SQL堆积趋势系统越来越卡2.2 第二步系统层排查系统层资源充足CPU飙升是MySQL自身造成的。2.3 第三步MySQL层深度排查① 查看当前所有连接mysql -e SHOW PROCESSLIST\G图4SHOW PROCESSLIST输出大量长时间运行查询发现异常多个查询运行时间超过30分钟而且State显示各种锁等待。② 用AI帮忙分析PROCESSLISTPROCESSLIST有几百行人工看太费劲。让AI帮忙分析【当前症状】- MySQL CPU从60%飙升到680%5-10分钟内- Threads_connected: 487正常50-100- Slow_queries: 1247- 多个查询Time超过1800秒状态为Locked/metadata lock【请分析】1. 这些长时间运行的查询最可能的原因是什么2. Locked 和 Waiting for table metadata lock 是什么关系3. CPU飙升和这些锁等待有什么关联③ 查看InnoDB状态mysql -e SHOW ENGINE INNODB STATUS\G关注以下关键信息2.4 第四步抽丝剥茧——定位根因图5根因链条——大查询被KILL后的雪崩效应经过完整的排查根因链条清晰了① 最初的触发点大查询被KILL但进程未退出-- 查看是否有过被KILL的查询SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE RUNNING;-- 查看事务运行时间SELECT id, time, state, info FROM information_schema.PROCESSLIST WHERE time 300;发现有一个查询运行超过1小时Time3600这个查询在之前被手动KILL了但进程清理未完成。② 连锁反应工作流阻塞 新请求堆积大查询被KILL后清理进程仍在消耗CPU。同时• 工作流依赖该查询结果无法继续执行• 工作流线程被阻塞在表锁上• 新的工作流请求不断堆积• 数据库连接数不断攀升487个③ 雪崩效应系统越来越卡① 大查询被KILL清理进程占用CPU② 表锁未释放工作流无法提交③ 新请求堆积连接数暴涨④ 新请求也变成慢查询⑤ CPU从60% → 280% → 680%⑥ 系统越来越卡 → 雪崩三、解决方案分步处理① 第一步KILL僵尸查询先清理掉那些长时间运行且无意义的查询-- 找出运行超过30分钟的查询SELECT CONCAT(KILL , id, ;) FROM information_schema.PROCESSLISTWHERE Command ! Binlog Dump AND Time 1800;-- 或者直接KILL特定IDKILL 15234; -- Time2847秒的查询KILL 15235; -- Time2156秒的查询KILL 15240; -- Time1890秒的查询② 第二步释放表锁如果KILL后锁仍未释放需要强制解锁-- 查看当前锁状态SHOW OPEN TABLES WHERE In_use 0;-- 查看元数据锁SELECT * FROM information_schema.INNODB_METRICS WHERE NAME LIKE metadata_lock%;-- 等待锁超时自动释放SET GLOBAL innodb_lock_wait_timeout 50; -- 调整为50秒③ 第三步扩容临时应对如果CPU仍然高可以临时扩容# 在负载均衡层限制流量# 或者临时增加MySQL服务器资源# 监控CPU下降情况④ 第四步索引优化根因解决找到那条运行1小时的查询分析为什么会这么慢-- 查看慢查询日志SHOW VARIABLES LIKE slow_query_log%;-- 查看执行计划EXPLAIN SELECT * FROM order_logs WHERE create_time 2024-01-01 ...;可能的问题四、效果验证五、预防措施六、AI辅助排查prompt模板遇到MySQL CPU飙升时这个prompt可以直接用【事故描述】MySQL CPU从正常值飙升到XX%系统变卡/无响应【已有的排查信息】- SHOW PROCESSLIST结果[粘贴关键行]- SHOW ENGINE INNODB STATUS结果[粘贴关键段落]- Threads_connected: XX- Slow_queries: XX【请分析】1. 最可能的3个根因方向2. 长时间运行的查询最可能是什么问题3. Locked/metadata lock 和CPU飙升有什么关系4. 应该优先KILL哪些查询七、经验总结这次MySQL CPU飙升的特殊之处在于——表面上是要优化慢查询实际上是一个被KILL的查询引发的连锁反应。这类问题的排查要点• 不要只看慢查询数量要看PROCESSLIST中Time最长的那些• 长时间运行的查询即使被KILL清理过程也可能消耗大量资源• 表锁/元数据锁会阻塞后续请求形成雪崩效应• 监控要关注连接数变化趋势比CPU告警更早发现问题排查顺序建议① SHOW PROCESSLIST → 找Time最长的查询② SHOW ENGINE INNODB STATUS → 看锁等待情况③ information_schema表 → 查事务和锁详情④ KILL僵尸查询 → 止血⑤ EXPLAIN慢查询 → 找根因⑥ 加索引/优化SQL → 治本