如何处理MySQL事务执行中连接意外断开？

事务执行中途断连且autocommit=False时，数据状态不可控：InnoDB不自动回滚未提交事务，仅保证已提交事务持久性；连接中断导致事务悬挂，可能部分写入或等待指令，重试易引发重复执行或误判回滚，必须结合SHOW ENGINE INNODB STATUS人工验证并辅以幂等设计与连接池健康检测。

事务执行中途断连，autocommit=False 时数据状态不可控

连接在 COMMIT 前中断，InnoDB 不会自动回滚已执行但未提交的语句——它只保证已提交事务的持久性，不保证“未提交事务一定被清理”。你看到的 OperationalError: (2013, 'Lost connection to MySQL server during query') 发生在事务中间，此时事务处于“悬挂”状态：服务器端可能已部分写入、也可能正在等待客户端指令，但客户端完全失去上下文。

常见问题表现包括：应用层捕获异常后直接重连并重试，结果导致同一笔业务被重复执行（如转账扣款两次）；或误以为事务已回滚，实际数据已被部分落盘。

1. 不要依赖 auto_reconnect=True 在事务中自动恢复——它只在语句执行前 ping 连接，无法感知事务上下文
2. 避免在事务内做耗时操作（如 HTTP 调用、文件读写），否则超时风险陡增
3. 务必在 try 块外显式关闭连接，否则连接池可能复用一个半死连接

SHOW ENGINE INNODB STATUS 是唯一能确认事务真实状态的手段

当怀疑事务是否已部分提交，不能靠日志或应用层判断。MySQL 重启后，InnoDB 会根据 redo log 和 undo log 自动恢复或回滚，但运行中必须人工介入验证。

执行 SHOW ENGINE INNODB STATUSG 后重点看 TRANSACTIONS 部分：

1. 查找 ACTIVE 状态且 mysql tables in use > 0 的事务，确认其 TRX_ID 和 TRX_STATE
2. 若显示 TRX_STATE: RUNNING 或 LOCK WAIT，说明事务仍在服务端挂起，需人工 KILL 对应线程
3. 若已消失，不代表已提交——可能是被 wait_timeout 强制中断后由 InnoDB 清理了，但清理前是否写盘需结合 redo log 刷盘位置判断

重试逻辑必须带幂等标识和事务边界重置

事务中断后重试不是简单“再连一次再跑一遍 SQL”，而是要重建完整事务语义。最稳妥的做法是：把业务操作封装成幂等单元，并在每次重试前确保旧连接彻底释放、新连接开启全新事务。

1. 在 SQL 层加唯一约束（如 INSERT ... ON DUPLICATE KEY UPDATE）或应用层生成业务 ID 做去重校验
2. 重试前调用 connection.close()，不要依赖连接池自动回收——有些池子（如 SQLAlchemy 的 NullPool）会缓存失效连接
3. 重连后必须显式调用 connection.begin() 或 start_transaction()，不能复用上一个连接对象的事务状态
4. 指数退避只适用于非事务场景；事务重试建议固定间隔（如 1s）+ 最多 2 次，超过即告失败并交由人工核查

根本解法：调高 wait_timeout 并配 ping=1 健康检查

90% 的“事务中途断连”其实源于 wait_timeout 设置过低（比如云厂商默认设为 300 秒），而连接池没做空闲检测。事务还没执行完，MySQL 已静默 kill 掉连接。

1. 在 my.cnf 中设 wait_timeout = 3600，并重启 MySQL（SET GLOBAL 临时生效但不持久）
2. 连接池初始化时启用 ping=1（PyMySQL）或 testOnBorrow=true（HikariCP），确保每次取连接都执行 PING 检测
3. 连接池的 maxLifetime 必须小于 wait_timeout（建议设为 wait_timeout * 0.8），避免连接在 MySQL 杀掉前就被池子主动淘汰

事务中断不是靠重试兜底的问题，而是连接生命周期管理失配的信号。一旦出现，优先查 wait_timeout 和连接池空闲配置，而不是堆重试代码。