MySQL数据库遇到的故障及分析_MySQL典型故障案例深度分析-php mysql-PHP中文网

主从复制中断表现为seconds_behind_master为null或持续增长，说明sql线程停止或卡住；连接数打满需排查应用层连接泄漏；ibdata1暴涨源于innodb_file_per_table关闭且无法在线收缩；慢查询cpu飙升多因sending data状态下的低效执行，需优化索引与分页逻辑。

mysql数据库遇到的故障及分析_mysql典型故障案例深度分析

主从复制中断：Seconds_Behind_Master 为 NULL 或持续增长

这通常不是延迟变大，而是复制已停止。执行 SHOW SLAVE STATUS\G 后看到 Seconds_Behind_Master: NULL，说明 SQL 线程没在运行；若数值持续上涨，大概率是 IO 线程正常但 SQL 线程卡住。

先检查 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes；任一为 No 就得查错
常见原因包括：从库遇到主库上不存在的表（如误删）、主键冲突、DDL 语句不兼容（如 ALTER TABLE ... ALGORITHM=INPLACE 在旧版本不支持）、GTID 模式下跳过事务失败
修复前务必确认 Relay_Log_File 和 Relay_Log_Pos，避免盲目 START SLAVE 导致数据不一致
若因唯一键冲突中断，不要直接 SET GLOBAL sql_slave_skip_counter = 1（仅适用于基于位置的复制），GTID 模式下必须用 gtid_next + BEGIN; COMMIT; 跳过

连接数打满：Too many connections 错误频繁出现

不是简单调大 max_connections 就能解决。真正的问题往往藏在应用层——连接未释放、长事务阻塞、或监控脚本高频探测。

先查当前活跃连接：SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';，重点关注 TIME 值大的线程
检查是否有未提交事务：SELECT * FROM information_schema.INNODB_TRX;，长时间 TRX_STATE = 'RUNNING' 的事务会占用连接并阻塞后续操作
应用侧常见陷阱：Java 中 Connection 没在 finally 块里 close()；Python 的 with 未正确包裹数据库操作；PHP 的 mysql_connect()（已废弃）反复新建连接
临时缓解可用 KILL 杀掉异常连接，但长期要加连接池（如 HikariCP）、设 wait_timeout 和 interactive_timeout 缩短空闲连接生命周期

InnoDB 表空间暴涨：ibdata1 不停增长且无法收缩

ibdata1 是共享表空间，默认存储数据字典、undo log、系统表等。一旦启用 innodb_file_per_table = OFF，所有表数据都会写进它，且 MySQL 不提供在线 shrink 功能。

度加AI

度加AI官网入口，百度官方 AIGC 创作平台，支持 AI 成片、AI 生文、数字人、声音克隆、配音字幕与智能剪辑等在线创作能力。

下载

确认是否启用了独立表空间：SHOW VARIABLES LIKE 'innodb_file_per_table';，值为 OFF 是隐患源头
如果已经暴涨，不能直接删 ibdata1——会导致实例启动失败；必须导出全部数据（mysqldump --all-databases --single-transaction），停库，清空数据目录，修改配置启用 innodb_file_per_table = ON，再重装导入
新部署务必默认开启 innodb_file_per_table；已有实例可逐个迁移：ALTER TABLE tbl_name ENGINE=InnoDB;（需确保磁盘有足够空间做重建）
注意 undo log 也会撑大 ibdata1，MySQL 5.7+ 可通过 innodb_undo_tablespaces 拆分，8.0+ 支持 innodb_undo_log_truncate 自动截断

慢查询导致 CPU 飙升：show processlist 显示大量 Sending data 状态

Sending data 并非网络传输，而是指 MySQL 正在处理查询结果（如排序、分组、生成临时表）。该状态耗时长，基本等于执行本身慢，不是网络问题。

开启慢日志：SET GLOBAL slow_query_log = ON;，配合 long_query_time = 1 捕获 >1 秒的查询
重点看执行计划：EXPLAIN FORMAT=TREE SELECT ...（8.0+）或 EXPLAIN ANALYZE（8.0.18+），确认是否走了索引、是否用到 filesort / temporary
典型诱因：ORDER BY RAND()、SELECT * 配合大 LIMIT、JOIN 多张大表没关联字段索引、JSON 字段全表扫描（JSON_CONTAINS() 无虚拟列索引）
优化优先级：加复合索引 > 改写查询逻辑（如用游标分页替代 LIMIT offset, size） > 开启 innodb_buffer_pool_size（建议设为物理内存 70%~80%）

SELECT 
  id, 
  name, 
  created_at 
FROM users 
WHERE status = 1 
ORDER BY created_at DESC 
LIMIT 100000, 20;

这种写法在 OFFSET 很大时，MySQL 仍要扫描前 100020 行。改成用上一页最大 created_at 值做条件更高效：

SELECT 
  id, 
  name, 
  created_at 
FROM users 
WHERE status = 1 
  AND created_at <p>真实故障里，最常被忽略的是配置与业务节奏的错配——比如凌晨批量 job 用默认 <code>innodb_lock_wait_timeout=50</code>，而报表任务实际需要 300 秒，结果大量锁等待超时回滚，反而加剧并发压力。</p>