会，仅当连接异常终止（如kill -9、网络静默中断、wait_timeout超时、KILL CONNECTION或服务重启）且autocommit=0时，MySQL服务端才主动回滚未提交事务。
会，但只在特定条件下自动回滚：连接异常终止 + autocommit=0 + 事务尚未 COMMIT 或 ROLLBACK。
哪些断开场景会触发自动回滚
MySQL 服务端只有在「确认连接已丢失」且该连接处于手动事务模式时，才会清理并回滚未提交事务。关键不是“断开”这个动作本身，而是服务端是否还持有该连接的会话上下文：
-
kill -9进程、客户端崩溃、网络静默中断（如拔网线）——服务端无法收到 FIN 包，需依赖超时机制判定断连，之后回滚 -
wait_timeout或interactive_timeout超时（默认 8 小时），服务端主动关闭空闲连接，并回滚其未提交事务 - 执行
KILL CONNECTION <id>—— 立即终止连接并回滚；但KILL QUERY <id>只中断当前语句，事务仍打开 - MySQL 服务重启 —— 所有活跃连接中断，所有未提交事务丢弃
注意：conn.close() 在应用层正常调用（如 Python 的 mysql-connector）、或客户端输入 EXIT，属于“正常断开”，MySQL 会先尝试完成清理，但不保证回滚——尤其当驱动未显式发送 QUIT 包时，服务端可能仍认为连接存活几秒。
为什么有时候看起来没回滚
常见错觉往往来自配置或中间件掩盖了真实行为：
-
autocommit=1模式下，每条语句已隐式COMMIT，断开前数据早已写入，自然“还在” - 用了连接池（如 HikariCP、Druid），连接回收时会自动执行
RESET CONNECTION或ROLLBACK，你看到的是池的行为，不是原始 MySQL 的反应 - 误判“断开”时机：比如事务中刚执行完
SELECT ... FOR UPDATE就卡住，但服务端还没到wait_timeout，此时事务仍持锁、未回滚，其他连接会等锁超时
验证方法：断开前查 SELECT TRX_ID, TRX_STATE FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID();；断开后再查，记录消失即表示已回滚。
DDL 语句会让事务提前提交，别被它骗了
CREATE、ALTER、DROP 等 DDL 在 InnoDB 中会隐式触发 COMMIT，导致前面所有 DML 一并提交——这不是“自动回滚”的反例，而是事务被中途强制结束。
- 执行
START TRANSACTION; INSERT ...; ALTER TABLE ...;后，即使没写COMMIT，INSERT也已落地 - 此时再断开连接，不会回滚那个
INSERT，因为它已被 DDL 隐式提交了 - 这个行为不受
autocommit设置影响，是存储引擎级硬规则
真正容易被忽略的是：InnoDB 回滚大量数据时，要重放 undo log，可能耗时数秒甚至更久——这期间连接线程仍被占用，且其他事务无法获取被锁资源，不是“瞬间完成”的清理。
