MySQL事务中途断开后，未提交事务会自动回滚吗？

本文共计764个文字，预计阅读时间需要4分钟。

在MySQL中，若设置`autocommit`为`0`，则事务需通过执行`COMMIT`或`ROLLBACK`来手动提交或回滚。当客户端连接丢失（如客户端崩溃、网络中断、超时断开等）时，MySQL服务端会主动清理该连接所持有的所有未提交的更改。这不是事务超时机制，而是连接生命周期管理的一部分。

哪些断开场景会触发自动回滚？

关键判断依据是：MySQL 是否还持有该连接的会话上下文。以下情况会触发回滚：

• 客户端进程被 kill（如 kill -9）或意外退出
• TCP 连接因网络故障静默中断（无 FIN 包）
• wait_timeout 或 interactive_timeout 超时（默认 28800 秒），连接空闲超时后被服务端主动关闭
• MySQL 服务重启（所有活跃连接中断，未提交事务全部丢弃）

注意：KILL CONNECTION <id> 命令也会立即终止连接并回滚未提交事务；但 KILL QUERY <id> 只中断当前语句，不终止连接，事务仍保持打开状态。

为什么有时候看起来“没回滚”？

常见错觉来源有三类：

• autocommit=1 模式下，每条语句本身就是独立事务，断开前语句已隐式提交，自然“留痕”
• 应用层使用连接池（如 HikariCP、Druid），连接断开后被池回收并重置（执行 RESET CONNECTION 或 ROLLBACK），掩盖了原始行为
• 误判“断开”时机：例如事务中执行了 SELECT 后客户端卡住，但 MySQL 还没判定超时，此时修改仍在事务内，尚未回滚

验证方法：在断开前查 SELECT TRX_ID, TRX_STATE FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = <your_thread_id>；断开后再查，记录消失即表示已回滚。

如何让未提交事务更可控？

依赖自动回滚是危险的，尤其在长事务或分布式调用中。建议主动控制：

• 设置合理超时：SET SESSION wait_timeout = 60（配合应用层心跳）
• 显式管理事务边界：避免在事务中做耗时 I/O（如 HTTP 调用、文件读写）
• 监控活跃长事务：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 30
• 应用层捕获 MySQL server has gone away 或 Lost connection to MySQL server during query 错误，并设计重试+补偿逻辑

真正容易被忽略的是：InnoDB 的回滚段（rollback segment）在事务回滚时需重放 undo log，若事务已修改大量数据，回滚本身可能耗时数秒甚至更久——这期间该连接线程仍被占用，且无法被其他操作复用。