性能影响分析
长事务会持续占用事务相关资源，包括未提交的行版本、undo 日志和锁，导致 InnoDB 缓冲池和日志系统的压力增加。
写入流量与 I/O 延迟上升，因为事务在提交前需要写入 redo log、undo log，如果事务时间过长，磁盘 I/O 会成为瓶颈，吞吐量下降。
在分析线上性能时，应关注事务持续时间、活跃事务数量和锁等待时间等指标，以判断是否进入了“长事务”导致的瓶颈。下面列出一个典型的 SQL 场景来说明。
-- 会话1
START TRANSACTION;
UPDATE orders SET status='processing' WHERE id=1001;
-- 长时间处理，未提交
SELECT SLEEP(120); -- 模拟耗时
COMMIT;大量未完成事务会增加 undo 使用量，undo 日志依赖于事务生命周期；如果出现长时间未提交，undo 表和 ibuf 的占用会持续增长。
此外，对快照版本的需求也会拉高内存压力，InnoDB 的 MVCC 必须在缓冲池中保留旧版本以读取历史数据，这会消耗更多的内存空间。
锁与阻塞机制
行锁、间隙锁与长事务的关系
长事务容易造成行锁滞留，尤其在更新大量行时，所需锁的范围会扩展，导致其他查询被阻塞。
InnoDB 的行锁和间隙锁会为满足一致性读而持续存在，直到事务结束，这意味着并发性能会随时间推移下降。
对于热区数据，锁的粒度与访问模式决定了并发吞吐量，若事务设计不佳，可能会经常升级锁，导致更高的等待时间。
-- 会话A
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE product_id = 101;
-- 期间未提交
-- 会话B
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE product_id = 101;
COMMIT;
死锁与超时风险
跨表或跨行的锁顺序冲突容易引发死锁，InnoDB 会检测并回滚其中一个事务以打破循环，然而这会带来额外的重试成本。
在高并发场景，长事务往往提高锁等待的概率，锁等待超时和死锁检测的开销会显著影响吞吐。
-- 会话A
START TRANSACTION;
UPDATE t1 SET v = v+1 WHERE id = 1;
UPDATE t2 SET v = v+1 WHERE id = 2;
COMMIT;-- 会话B
START TRANSACTION;
UPDATE t2 SET v = v+1 WHERE id = 2;
UPDATE t1 SET v = v+1 WHERE id = 1;
COMMIT;
数据一致性与可恢复性
MVCC 与版本链的影响
MVCC 通过版本链实现一致性读，长事务会保留更多未提交版本，导致 undo 与版本快照在缓冲池中占用更多空间。
这会提升内存使用和 I/O 负载，在高并发中易造成读操作的延迟增加，尤其是需要大量历史版本的读请求。
合理的监控可以帮助区分长事务导致的版本膨胀和应用层面的问题。
-- 使用快照读获取历史版本示例（伪代码）
SELECT * FROM orders WHERE id = 1001;
崩溃与回滚带来的影响
服务器崩溃或实例崩溃时，未提交事务需要回滚，这会产生大量 undo 日志的回滚工作，影响恢复时间和系统可用性。
如果应用层有跨节点分布式事务，长事务更会使回滚成本上升，恢复点和故障恢复时间变长。
-- 崩溃后需要回滚示例
ROLLBACK;
