会，仅当连接异常终止（如崩溃、网络中断、超时）且 autocommit=0 时，MySQL 服务端会主动回滚未提交事务；正常断开或 autocommit=1 下不适用。
MySQL 连接断开时未提交事务会自动回滚吗？
会，但仅限于「连接异常终止」（如客户端崩溃、网络中断、超时断连），且前提是 autocommit=0 且事务尚未执行 COMMIT 或 ROLLBACK。MySQL 服务端在检测到客户端连接丢失后，会主动清理该连接持有的所有未提交更改——这不是“事务超时机制”，而是连接生命周期管理的一部分。
哪些断开场景会触发自动回滚？
关键判断依据是：MySQL 是否还持有该连接的会话上下文。以下情况会触发回滚：
- 客户端进程被 kill（如
kill -9）或意外退出 - TCP 连接因网络故障静默中断（无 FIN 包）
-
wait_timeout或interactive_timeout超时（默认 28800 秒），连接空闲超时后被服务端主动关闭 - MySQL 服务重启（所有活跃连接中断，未提交事务全部丢弃）
注意：KILL CONNECTION <id></id> 命令也会立即终止连接并回滚未提交事务；但 KILL QUERY <id></id> 只中断当前语句，不终止连接，事务仍保持打开状态。
为什么有时候看起来“没回滚”？
常见错觉来源有三类：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
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></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，若事务已修改大量数据，回滚本身可能耗时数秒甚至更久——这期间该连接线程仍被占用，且无法被其他操作复用。
