MySQL 长事务有什么危害？怎么发现和处理一直不提交的事务？

知识点详解：没有在执行 SQL，也可能留下一个很老的事务

先区分慢 SQL 与长事务

咱们假设应用开启事务，查询订单，再等待用户确认。查询可能只用了几毫秒，但用户迟迟没有操作，事务一直没有提交。

慢查询统计可能看不出这个问题，因为没有一条 SQL 持续很长时间。事务却仍然占用相应状态和资源。

MySQL 的事务信息说明提供了 InnoDB 活跃事务与等待信息的入口。因此，监控不能只关注单条 SQL 耗时，也要关注事务年龄。

锁与旧版本，分别造成不同压力

修改数据的事务可能持有记录锁，让其他事务等待。具体是否持锁、持有什么锁，要看实际语句和隔离级别。

读取事务则可能保留一致性读取需要的历史版本。并不是“长事务让所有 undo 都不能清理”，而是有些版本仍被旧读取视图需要，清理进度受到约束。

MySQL 的 purge 文档解释了清理相关配置与影响。历史长度上升是一个观察信号，不能仅凭一个指标就锁定某个连接；写入速率和清理能力也会影响它。

两组历史按“是否仍被读取视图需要”分类，不表示同一版本链的时间先后。

用事务记录，找回对应连接

可以先查询活跃事务的时间和连接信息，再结合 Performance Schema 或 processlist 找到实际会话。下面为只读排查示例，字段与权限需要按数据库版本确认。

SELECT trx_id, trx_started, trx_state,
       trx_mysql_thread_id, trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

trx_query 为空，不等于事务不存在。会话可能现在空闲，但以前开启的事务仍未结束。连接状态为 Sleep，也不能自动排除这种情况。

继续检查锁等待、应用日志和请求标识，确定是谁开启事务、为什么没有结束。事务开始时间很早，但当前没有明显阻塞，和正在锁住核心写入的事务，处理优先级不同。

终止之前，要考虑回滚本身的代价

如果事务修改了很多数据，回滚可能需要时间。终止连接不代表所有影响立刻消失，相关清理也需要完成。

因此，应先确认业务是否允许中断，记录诊断信息，再与负责方决定处理方式。不能把一条 kill 命令作为普适修复，更不能在没有确认时对生产会话执行它。

如果问题源于连接归还池之前没有提交或回滚，要修复资源管理。连接池复用可以让问题延续到其他请求，单次终止只能缓解现象。

把事务范围缩到真正需要原子性的部分

不要在数据库事务里等待用户输入、执行长时间外部请求或做大量无关计算。

可以在事务外准备数据，在短事务中完成必须一致的检查和修改；确实需要跨步骤业务状态时，用明确状态与补偿机制组织，不让数据库连接替整个业务流程无限等待。

最后增加事务年龄、锁等待、回滚耗时和历史清理等监控，并测试异常路径。只给正常路径添加 commit，不检查超时和异常是否 rollback，仍然可能留下长事务。

面试官继续追问

只读事务是不是一定无害？

不是。是否影响历史清理，要看读取视图、隔离级别和执行方式。但也不能说任何只读查询都会永久保留旧版本。

长事务一定会锁住整张表吗？

不一定。锁范围由实际操作、索引和隔离机制等决定；长只是持续时间描述，不是锁类型。

处理以后怎样确认恢复？

继续观察等待、活跃事务、回滚和历史清理趋势，并检查业务请求。连接消失只是一个事实，不是全部恢复证明。

面试速记卡

• 长事务：事务状态持续，不等于一条慢 SQL。
• 两类压力：锁等待与历史版本清理受影响。
• 空闲边界：Sleep 连接也可能保留未结束事务。
• 处理原则：先确认业务与回滚成本，再决定中断。
• 长期治理：缩小事务范围，覆盖异常和资源释放。