长事务会把锁“焊死”在数据上
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，也会隐式开启事务——连接不断，事务就不关 事务不是越长越安全，是越长越危险。真正难防的不是大事务，而是那种“只改一行、但卡在日志打印或下游响应里”的小事务——它不占资源、不报错、监控阈值也抓不住，却能把整个链路拖垮。
