mysql如何解决由于磁盘空间不足导致的事务挂起_自动清理过期事务-mysql教程-PHP中文网

磁盘空间不足会触发mysql保护机制导致事务悬挂，需先用df -h检查/var/lib/mysql分区及ibtmp1路径使用率是否≥95%，再查error.log中os error code 28等错误，最后通过innodb_trx筛选长时间running却无进展的事务。

mysql如何解决由于磁盘空间不足导致的事务挂起_自动清理过期事务

磁盘空间不足本身不会直接导致事务挂起，但会触发 MySQL 的保护机制（如写 binlog 失败、无法扩展 undo log、临时文件写入失败），进而让事务卡在“等待 I/O”或“等待锁”状态，表现为 trx_state = 'RUNNING' 却无实际执行进展——这正是悬挂事务（zombie transaction）的典型特征。清理这类事务不能只看“时间长”，得看“是否真在干活”。

怎么确认是磁盘不足引发的悬挂事务

先查磁盘和错误日志，别急着 KILL：

用 df -h 检查 /var/lib/mysql 所在分区是否 Use% ≥ 95%；特别注意 ibtmp1（临时表空间）所在路径，它不走 datadir 但可能单独占满磁盘
查 MySQL 错误日志：tail -n 100 /var/log/mysql/error.log，重点搜 OS error code 28（No space left on device）、Failed to write to binlog、Cannot create temporary file
再查悬挂事务：SELECT trx_id, trx_state, trx_started, trx_query, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_started —— 这类才是真可疑对象

为什么不能直接定时 KILL 所有“老事务”

盲目 KILL 会破坏业务一致性，比如一个正在做批量导入的长事务，trx_query 可能为空（因处于锁等待或内部阶段），但它不是僵尸。真正该杀的是：

状态为 RUNNING 且 trx_query 为空或为 NULL
启动时间早于某个阈值（如 5 分钟），且期间无任何 trx_operation_state 变化（需结合 INFORMATION_SCHEMA.INNODB_TRX 和 PROCESSLIST 对比）
对应线程在 SHOW PROCESSLIST 中显示为 Sleep 或 Locked，而非 Query 或 Updating

所以存储过程里必须加 trx_query IS NULL OR trx_query = '' 判断，不能只靠 trx_started。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

如何安全自动清理：事件 + 存储过程 + 日志闭环

推荐用 MySQL 原生 EVENT 调度，但必须满足三个前提：调度器开启、账号有 EVENT 权限、操作留痕可追溯。

开启调度器（永久）：在 my.cnf 的 [mysqld] 段加 event_scheduler = ON，重启生效
授权账号：GRANT EVENT ON mydb.* TO 'cleaner'@'localhost'（别给 *.*，最小权限原则）

建带日志的存储过程（示例只删 5 分钟以上无查询的事务）：

DELIMITER $$
CREATE PROCEDURE cleanup_zombie_trx()
BEGIN
  DECLARE done INT DEFAULT FALSE;
  DECLARE v_trx_id VARCHAR(18);
  DECLARE v_thread_id BIGINT;
  DECLARE cur CURSOR FOR 
    SELECT trx_id, trx_mysql_thread_id 
    FROM information_schema.INNODB_TRX 
    WHERE trx_state = 'RUNNING' 
      AND trx_started OPEN cur;
read_loop: LOOP
FETCH cur INTO v_trx_id, v_thread_id;
IF done THEN LEAVE read_loop; END IF;
INSERT INTO cleanup_log VALUES (NOW(), v_thread_id, v_trx_id, 'killed');
KILL v_thread_id;
END LOOP;
CLOSE cur;
END$$
DELIMITER ;

建事件调用它：CREATE EVENT ev_cleanup_zombie ON SCHEDULE EVERY 30 SECOND DO CALL cleanup_zombie_trx()

磁盘清理后事务仍卡住？检查 undo 表空间和 binlog

即使删了文件腾出空间，InnoDB 的 undo_001 文件可能已损坏或膨胀到无法收缩，binlog 也可能因写入失败而卡住复制位点。这时要：

确认 innodb_undo_tablespaces 是否为 0（MySQL 8.0.23+ 默认 2），若设为 0 则 undo 在系统表空间内，无法在线 shrink，只能重建实例
运行 SHOW BINARY LOGS; 看最老 binlog 是否远早于当前时间，若是，用 PURGE BINARY LOGS BEFORE '2026-04-10 00:00:00'; 清理（注意主从延迟）
检查 innodb_max_undo_log_size 是否过小导致频繁分配新 undo 段，建议设为 2G+（需重启）

真正棘手的不是“怎么删”，而是“删完之后 undo 和 binlog 是否还带着病灶继续拖慢后续事务”——这点常被忽略。