长事务会把锁“焊死”在数据上，导致写阻塞写、写阻塞读、ddl排队、undo log膨胀、主从延迟加剧及连接池耗尽。
长事务会把锁“焊死”在数据上
InnoDB 本身不会把行锁升级成表锁，但长事务会让 next-key lock 持有时间拉得极长——哪怕只改了一行，它连带锁住索引间隙，其他事务一碰就卡住。更糟的是，TRX_ROWS_LOCKED 和 TRX_LOCK_STRUCTS 在 information_schema.INNODB_TRX 里持续涨，看起来像整张表被锁了。
- 常见现象：
SHOW PROCESSLIST里一堆Updating或Waiting for table metadata lock；简单UPDATE耗时几秒甚至几十秒 - 容易踩的坑：只看
trx_state = 'RUNNING'就以为事务还在干活，其实可能是空闲等待（比如应用忘了COMMIT），trx_query为空才是关键信号 - 真实影响：写阻塞写、写阻塞读（尤其
REPEATABLE READ下 MVCC 版本链爆炸）、DDL 操作集体排队
undo log 不清理，磁盘和 CPU 一起崩
长事务不提交，undo log 就不能被 purge 线程回收。它不只是占空间——ibdata 或独立 undo 表空间持续膨胀，还会拖慢整个实例的 MVCC 读性能。
- 为什么严重：purge 线程忙于清理旧版本，导致其他事务查数据时遍历超长版本链，CPU 和 IO 都吃紧
- 典型场景：一个事务跑了 5 分钟，期间所有新事务的快照都得绕过它生成的全部 undo 记录
- 配置补救：
innodb_undo_log_truncate=ON可自动截断过期段，但前提是事务别卡太久，否则 truncate 根本触发不了
主从延迟不是网络问题，是事务太“沉”
主库上长事务提交那一刻，Binlog 才刷盘；从库得重放这一大坨变更。不是同步慢，是“单次任务太重”。尤其当事务内含大量更新，从库 SQL 线程可能卡住几十秒不动。
- 连锁反应：主库 Binlog 缓存（
binlog_cache_size）被占满，其他小事务被迫等；从库延迟监控突然跳升，但Seconds_Behind_Master显示为 0（因为还没开始执行） - 误判风险：运维常以为是网络或复制线程挂了，实际是主库上某个
UPDATE卡了 3 分钟没提交 - 验证方法：在从库执行
SHOW SLAVE STATUS\G，重点看Exec_Master_Log_Pos是否长期不动，再回主库查INNODB_TRX对应trx_id
连接池耗尽比锁表更致命
一个长事务 = 一个连接被钉住。如果用 HikariCP 之类连接池，且最大连接数设为 20，20 个长事务同时跑，新请求直接拿不到连接——HTTP 500、超时、熔断全来，比数据库慢还难排查。
- 开发侧盲区：事务边界没用
try-finally包裹，异常时漏掉ROLLBACK；或 HTTP 请求处理中开了事务，却在调外部 API 时卡住 - 实操建议：在应用层加事务超时（如 Spring 的
@Transactional(timeout = 5)），比靠 DB 层max_execution_time更早兜底 - 最隐蔽的坑：某些 ORM 框架（如旧版 MyBatis）在
autocommit=0连接上执行单条SELECT，也会隐式开启事务——连接不断，事务就不关
