由 dawei MySQL突发故障常表现为事务阻塞、慢查询暴增或连接数飙升。此时需快速定位根因，而非盲目重启。优先检查show processlist输出，重点关注State为“Sending data”“Locked”或“Waiting for table metadata lock”的会话，它们往往指向长事务或未提交操作。
长事务是性能雪崩的常见诱因。执行select from information_schema.innodb_trx order by trx_started limit 5可识别运行超30秒的事务。立即kill对应线程ID，并结合binlog和应用日志回溯业务逻辑，确认是否遗漏commit或存在异常循环。
表锁与MDL（元数据锁）争用易被忽略。若出现大批会话卡在“Waiting for table metadata lock”，说明有DDL操作（如alter table）被阻塞，或存在未关闭的显式事务持有表级锁。可通过performance_schema.metadata_locks视图精准定位持有者，及时终止源头会话。
AI生成内容图，仅供参考
慢查询突增时，禁用“只看执行计划”的惯性思维。先查slow_log中Rows_examined远大于Rows_sent的SQL，这类语句通常缺乏有效索引或使用了不当的like前缀模糊匹配。临时添加force index或修改查询条件可快速止损，再评估是否需重构索引。
连接数耗尽常源于应用端连接池配置失当或MySQL max_connections设置过低。应急可动态调高：set global max_connections=1000；但更关键的是检查show status like ‘Threads_connected’与Threads_created趋势，确认是否频繁创建新连接——这往往指向应用未正确复用连接。
优化不是单点修补。每次故障后应固化检查清单：事务平均时长、QPS/TPS突变点、InnoDB buffer pool hit rate是否骤降、unpurged trx数量是否持续增长。将这些指标接入监控告警，才能把被动救火转化为主动防控。