ERROR 1114和Lock wait timeout exceeded本质是长事务阻塞purge导致undo空间耗尽或锁等待超时；History list length过高、innodb_undo_tablespaces=0、purge线程停滞是关键原因；需杀掉源头长事务而非调参。
这不是“Undo Log溢出”报错，MySQL 5.7根本不会抛出这个字面错误——你看到的ERROR 1114 (HY000): The table 'xxx' is full 或 Lock wait timeout exceeded，本质是长事务阻塞purge导致undo空间耗尽或锁等待超时。
为什么ERROR 1114实际是undo空间被卡死，不是磁盘真满了
当一个事务长时间不提交（比如执行了20分钟的UPDATE），它产生的所有undo log都不可被purge线程清理。History list length持续上万，undo页越积越多，但新事务仍要分配undo段——此时即使磁盘还有几十GB空闲，InnoDB也会因无法获取可用undo slot而拒绝写入，直接报ERROR 1114。
- 查证方式：
SHOW ENGINE INNODB STATUS\G里找HISTORY LIST LENGTH，>5000就危险；再查SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_undo_tablespaces';，值为0说明undo还在共享表空间（ibdata1），根本无法收缩 -
innodb_undo_log_truncate = ON在5.7中默认关闭，且即使开启，也依赖innodb_purge_rseg_truncate_frequency（默认128）来触发截断——长事务存在时，purge压根不跑，truncate永远不生效 - 别删业务表数据：undo空间不随
DELETE释放，只靠purge线程回收已提交事务的旧版本
Lock wait timeout exceeded为什么常在ROLLBACK时出现
这个错误名极具误导性。它不是回滚失败，而是MySQL在执行ROLLBACK前，先尝试重新获取自己之前修改过的那些行的X锁——结果发现这些行正被另一个未提交的长事务锁着，等了innodb_lock_wait_timeout（默认50秒）没等到，就直接放弃并报错。
- 典型链路：事务A大更新后未提交 → 事务B想更新同一行 → B等锁 → 超时 → B报
Lock wait timeout exceeded；此时若A执行ROLLBACK，同样会卡在这一步 - 查谁在持锁：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND TIME_TO_SEC(NOW() - trx_started) > 60; - 别只调
innodb_lock_wait_timeout：从50秒降到5秒能缩短等待，但治标不治本；必须同步杀掉源头长事务，否则新连接照常堵死
为什么max_execution_time对大事务完全无效
SET SESSION max_execution_time = 1000只作用于单条SELECT语句，对BEGIN; UPDATE ... ;这类事务内操作零影响。事务一旦开始，后续所有语句都在同一个事务上下文中运行，超时机制不介入。
- 常见误判场景：应用层开了
@transaction.atomic（Django）或session.begin()（SQLAlchemy），但漏了commit或rollback，结果整个连接挂着一个空闲事务，trx_state = 'RUNNING'，trx_rows_modified = 0，但锁和undo一直占着 - 监控关键字段：
INFORMATION_SCHEMA.INNODB_TRX里的trx_started、trx_state、trx_rows_modified三者要联合看，不能只盯trx_state - 自动终止脚本必须覆盖三类危险事务：运行超60秒未提交、持有锁但
PROCESSLIST.Command = 'Sleep'超30秒、trx_rows_modified > 100000
真正卡住undo释放的，从来不是日志量本身，而是那个迟迟不提交的事务——它像一根针，扎在purge链路上，让所有后续事务的undo都动弹不得。排查时优先砍掉最老的trx_id，比调任何参数都管用。
