MySQL 5.7中事务溢出本质是长事务、回滚段膨胀与锁等待堆积引发CPU/IO拉满、连接阻塞乃至OOM或kill导致宕机；max_execution_time仅作用于单条SELECT，对事务内UPDATE等无效，需监控并自动终止超时未提交、空闲持锁、修改行数超10万的三类危险事务，并协同调低innodb_lock_wait_timeout和wait_timeout。
MySQL 5.7 中事务溢出（本质是长事务 + 回滚段膨胀 + 锁等待堆积）不会直接报“事务溢出”错误，但会引发 CPU/IO 拉满、连接阻塞、最终触发 OOM 或主动 kill 导致实例宕机。单靠 max_execution_time 或调大 innodb_undo_tablespaces 都不能治本。
为什么 max_execution_time 对事务溢出完全无效
它只作用于单条 SELECT 语句，而事务溢出的典型场景是：一个事务里执行了 UPDATE + 大量数据扫描 + 未提交，此时 max_execution_time 不生效；innodb_rollback_segments 和 innodb_undo_log_truncate 在 5.7 中默认关闭或不可控，undo 表空间持续膨胀，Buffer Pool 被旧版本数据占满，最终触发系统级内存压力。
-
SET SESSION max_execution_time = 1000对BEGIN; UPDATE ...;这类语句零影响 - 事务内第一条语句超时后，事务仍保持打开状态，锁不释放，MVCC 视图持续老化
- 监控看到
INFORMATION_SCHEMA.INNODB_TRX中trx_started时间极早，但trx_state = RUNNING，说明事务卡在某个非 SELECT 步骤（比如等锁、刷脏页）
必须监控并自动终止的三类危险事务
在 MySQL 5.7 中，仅靠人工巡检来不及响应。需用定时脚本或外部工具（如 pt-kill）持续扫描 INFORMATION_SCHEMA.INNODB_TRX 和 PROCESSLIST：
-
运行超 60 秒且未提交的事务：
TIME_TO_SEC(NOW() - trx_started) > 60 AND trx_state = 'RUNNING' -
持有行锁但空闲（Sleep）超 30 秒的连接：对应
PROCESSLIST中Command = 'Sleep'且Time > 30，同时该线程 ID 出现在INNODB_TRX中 -
事务已修改超过 10 万行但仍未提交：查
trx_rows_modified > 100000（需配合SHOW ENGINE INNODB STATUS的 TRANSACTIONS section 辅助验证）
innodb_lock_wait_timeout 和 wait_timeout 必须协同调低
这两个参数不是“可选优化”，而是防雪崩的硬门槛。5.7 默认 innodb_lock_wait_timeout = 50 秒，意味着一个事务等锁最多耗 50 秒才失败——这期间它一直占用连接、锁、缓冲区。而 wait_timeout = 28800（8 小时），让空闲连接长期挂起，极易掩盖真实问题。
- 生产建议设为：
SET GLOBAL innodb_lock_wait_timeout = 10;（应用层需捕获Lock wait timeout exceeded并重试） -
SET GLOBAL wait_timeout = 60;（短连接场景）或300（长连接但有心跳机制） - 注意：
wait_timeout只对新连接生效，已存在的 Sleep 连接不受影响，需搭配pt-kill --idle-time 60清理
真正起效的配置组合（MySQL 5.7 生产实测）
光改参数没用，必须让它们形成闭环。以下配置在 8GB 内存、并发 200+ 的 5.7 实例中稳定运行 18 个月：
-
innodb_buffer_pool_size = 4G（不超过物理内存 50%，留足给 OS 和连接线程） -
innodb_undo_tablespaces = 2（虽已 deprecated，但在 5.7 是唯一能加速 undo 截断的方式） -
innodb_undo_log_truncate = OFF（5.7 不支持动态开启，但设为 OFF 可避免 truncate 失败导致 crash） - 配合外部脚本每 30 秒执行：
KILL QUERY或KILL符合上述三类条件的线程 ID - 应用端强制要求：所有事务必须显式
COMMIT或ROLLBACK，禁止隐式提交；网络请求类操作严禁放在事务内
最常被忽略的一点：事务溢出往往始于一个“看起来无害”的 UPDATE，但它在低隔离级别下触发了全表扫描 + 行锁升级，而 DBA 只盯着慢查询日志里的 SELECT ——结果就是，你优化了一堆查询，宕机依旧准时发生。
