连接数爆满 / Too many connections
出现概率★★★★★，严重程度★★★★★
常见表现为应用报1040错误，无法连接数据库。
核心排查命令：SHOW PROCESSLIST 结合 SHOW GLOBAL STATUS LIKE 'Threads_%'
解决方案：调整max_connections参数，引入连接池技术，优化慢查询，实施读写分离架构。
慢查询导致 CPU/IO 飙高
出现概率★★★★★，严重程度★★★★☆
典型现象包括CPU满载、磁盘IO等待高、响应延迟。
排查工具：启用slow_query_log，结合EXPLAIN ANALYZE分析执行计划。
优化手段：添加合适索引，重构低效SQL，部署读写分离，必要时降级或限流保护系统。
主从延迟过大
出现概率★★★★☆，严重程度★★★★☆
表现为从库数据滞后主库数分钟至数小时。
诊断命令：SHOW SLAVE STATUS\G（关注Seconds_Behind_Master字段）。
改进方案：启用并行复制，扩大relay_log容量，配置半同步复制，过滤非关键表同步。
死锁（Deadlock）
出现概率★★★★，严重程度★★★★
症状为事务长时间阻塞，返回1213错误码。
分析途径：SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK段落。
解决策略：调整事务执行顺序，压缩事务时长，降低隔离级别，使用锁提示（如FOR UPDATE）。
OOM Killer 终止 MySQL 进程
出现概率★★★★，严重程度★★★★★
表现为mysqld进程意外终止，系统日志记录Out of memory事件。
诊断方法：执行dmesg | grep -i kill或检查journalctl日志。
Binlog 写满磁盘 / 磁盘空间耗尽
出现概率★★★★，严重程度★★★★★
症状为数据写入失败，返回1118/1129错误。
排查命令：df -h查看磁盘空间，du -sh /var/lib/mysql/binlog*统计日志大小。
应对措施：配置binlog_expire_logs_seconds自动清理，扩容磁盘空间，迁移分区表数据。
UUID 主键引发插入性能劣化
出现概率★★★★，严重程度★★★☆
大表插入延迟加剧，innodb_flush_log_at_trx_commit=1时更显著。
分析命令：EXPLAIN显示type=index且rows值异常偏高。
优化方案：改用自增主键（AUTO_INCREMENT），或采用雪花算法/业务分段ID。
表空间碎片化严重
出现概率★★★☆，严重程度★★★
表现为磁盘占用率高，删除数据后空间未释放。
诊断命令：SHOW TABLE STATUS观察Data_free字段值。
处理方式：执行OPTIMIZE TABLE重整空间，或改用分区表并定期归档历史数据。
高并发场景 undo log 溢出
出现概率★★★，严重程度★★★★
症状包括事务回滚缓慢，undo表空间耗尽。
检查方法：SHOW ENGINE INNODB STATUS查看undo日志段。
优化建议：增大innodb_undo_log_truncate阈值，缩短事务执行时间。
临时表空间不足（tmpdir）
出现概率★★★，严重程度★★★★
GROUP BY/ORDER BY/UNION操作报1114错误。
诊断步骤：df -h /tmp或查看SHOW VARIABLES LIKE 'tmpdir'。
解决方案：调高tmp_table_size，将tmpdir指向大容量磁盘，优化SQL减少临时表生成。
字符集/排序规则不一致致索引失效
出现概率★★★，严重程度★★★
存在索引但执行计划显示全表扫描。
验证方法：对比SHOW CREATE TABLE与EXPLAIN的key字段。
根治措施：统一字符集为utf8mb4_unicode_ci或utf8mb4_0900_ai_ci。
连接泄漏（连接池未释放）
出现概率★★★，严重程度★★★★
现象为连接数持续增长直至耗尽。
定位命令：SHOW PROCESSLIST中存在大量Sleep状态连接。
修复方案：强制连接池回收资源，应用代码确保finally/close调用，设置连接超时终止。
半同步复制拖慢主库写入
出现概率★★☆，严重程度★★★
开启rpl_semi_sync后主库写入延迟上升。
监控指标：SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync%'。
调整建议：增加rpl_semi_sync_master_timeout阈值，评估半同步复制必要性。
大事务引发 undo 表空间膨胀
出现概率★★☆，严重程度★★★★
批量更新/删除后undo空间快速扩张。
检查方法：SHOW ENGINE INNODB STATUS观察undo日志状态。
规避措施：拆解大事务为小批次，启用innodb_rollback_on_timeout。
统计信息不准导致索引误选
出现概率★★☆，严重程度★★★
执行计划未选用最优索引，尽管数据分布均匀。
验证步骤：对比ANALYZE TABLE前后的执行计划差异。
长效方案：定期执行ANALYZE TABLE，启用innodb_stats_persistent持久化统计信息。
最常用的一套排查组合拳（背下来，基本能解决 80% 问题）
当遇到线上 MySQL 异常时，优先执行以下 5 个命令（顺序重要）：
-- 1. 看当前正在执行什么（永远是第一步！）
SHOW FULL PROCESSLIST;
-- 2. 看慢查询和状态指标（全局快照）
SHOW GLOBAL STATUS LIKE 'Threads_%';
SHOW GLOBAL STATUS LIKE 'Innodb%';
SHOW GLOBAL STATUS LIKE 'Handler%';
-- 3. 看当前最重的查询（MySQL 8.0+ 强烈推荐）
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
-- 4. 看最近死锁（如果有死锁基本都在这里）
SHOW ENGINE INNODB STATUS\G
-- 5. 看复制状态（主从环境必看）
SHOW SLAVE STATUS\G
SHOW MASTER STATUS;2025-2026 年最实用的调优建议清单（直接抄）
# 连接数相关（高并发必调）
max_connections = 5000~20000 # 根据机器内存调整
thread_cache_size = 1024 # 连接复用
wait_timeout = 30 # 空闲连接快速回收
interactive_timeout = 30
# InnoDB 核心（内存命中率是关键）
innodb_buffer_pool_size = 总内存*0.6~0.8
innodb_buffer_pool_instances = CPU核心数*2（不超过64）
innodb_flush_log_at_trx_commit = 2 # 高性能场景可调为2（牺牲少量耐久性）
# 日志与复制
binlog_expire_logs_seconds = 604800 # 7天
expire_logs_days = 7 # 老版本用
relay_log_recovery = 1 # 从库崩溃安全恢复
slave_parallel_workers = 8~32 # 并行复制线程数一句话总结（贴在工位上都行）
"MySQL 线上出问题，80% 逃不过这六件事：连接数爆、慢查询、磁盘满、主从延迟、死锁、统计信息不准。"
把 SHOW PROCESSLIST、EXPLAIN ANALYZE、SHOW ENGINE INNODB STATUS 这三板斧练熟，再结合上面清单中的参数调优，大部分 MySQL 生产事故都能在 10 分钟内定位并给出初步解决方案。