长事务为什么会导致行锁升级为表锁
MySQL 的 InnoDB 引擎本身不直接“升级”行锁为表锁，但长事务会显著延长
next-key lock的持有时间，导致其他事务在相同索引范围上被阻塞——看起来像锁了整张表。更关键的是，当事务长时间未提交，
information_schema.INNODB_TRX中的
TRX_ROWS_LOCKED和
TRX_LOCK_STRUCTS会持续增长，而 MVCC 的历史版本（undo log）无法被 purge 线程及时清理，进而拖慢整个实例的并发性能。
常见现象包括：
SHOW PROCESSLIST中大量线程处于
Waiting for table metadata lock或
Updating状态；
SELECT * FROM performance_schema.data_locks显示大量重叠的
RECORD锁；慢查询日志中出现本该毫秒级的简单
UPDATE却耗时数秒以上。 长事务期间所有已修改的行都保持
X锁，即使只更新了一行，其相邻索引间隙也被
next-key lock覆盖
autocommit=0下手动开启事务但忘记
COMMIT或
ROLLBACK是最常见诱因 应用层使用连接池（如 HikariCP）时，若未显式控制事务边界，可能让一个 HTTP 请求持有一个长达几十秒的事务
如何快速定位正在运行的长事务
别只看
SHOW PROCESSLIST，它不显示事务开始时间。真正有效的是查
performance_schema或
information_schema中带时间戳的视图：
SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id AS thread_id, trx_query, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_sec FROM information_schema.INNODB_TRX WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 60 ORDER BY duration_sec DESC;
注意：
trx_started是事务实际启动时间，不是连接建立时间；
trx_state = 'RUNNING'不代表事务活跃，也可能是空闲等待（比如应用没发
COMMIT）。如果启用了
performance_schema，还可结合
data_lock_waits查谁在等谁： 优先过滤
duration_sec > 60，生产环境建议阈值设为 30 秒 检查
trx_query是否为空 —— 空值表示事务已执行完语句但尚未提交 用
KILL [thread_id]终止前，务必确认该事务不属于关键批处理流程（如账务对账）
避免长事务的实操策略
根本解法不是“杀掉”，而是从应用和 SQL 层杜绝长事务产生。重点不在语法，而在执行路径设计：
所有写操作必须包裹在明确的BEGIN/
COMMIT块内，禁止跨函数/跨 HTTP 请求隐式延续事务 大更新拆分为小批量：用
WHERE id BETWEEN ? AND ?分页，每次最多更新 1000 行，并在循环中
COMMIT读多写少场景下，避免在事务中执行耗时操作：如调用外部 HTTP 接口、生成 PDF、发送邮件 —— 这些必须挪到
COMMIT之后 ORM 框架（如 MyBatis、SQLAlchemy）中慎用
@Transactional(propagation = Propagation.REQUIRED)套在 Service 方法上，尤其当方法内部含远程调用时
MySQL 侧可加一层防护：
SET GLOBAL innodb_lock_wait_timeout = 10;（默认 50），缩短等待锁的超时时间，让失败更快暴露；但注意这不能替代业务层优化，只是兜底手段。
长事务对备份与主从延迟的影响
物理备份（如
mysqldump --single-transaction）依赖一致性快照，若备份期间存在运行超 1 小时的长事务，
mysqldump会卡在
Waiting for backup lock；逻辑备份则可能因 undo log 膨胀导致
SELECT变慢甚至 OOM。
主从复制中，长事务在主库执行完毕后才写入 binlog，但从库必须串行回放——如果主库上一个
UPDATE花了 90 秒，从库也会卡住 90 秒，表现为
Seconds_Behind_Master持续飙升，且
SHOW SLAVE STATUS中
Exec_Master_Log_Pos长时间不推进。 监控项必须包含：
max(innodb_trx.trx_started)的倒序差值，即“最长事务存活秒数” Percona Toolkit 的
pt-kill --busy-time 60 --kill可配置为定时巡检脚本，但需白名单排除 DBA 维护类事务 DDL 操作（如
ALTER TABLE）在 MySQL 5.6+ 默认在线，但仍会尝试获取
metadata lock，若此时有长事务正持有该表的任何锁，DDL 就会无限等待
最易被忽略的一点：连接空闲超时（
wait_timeout）不会中断事务，只断开连接。也就是说，一个设置了
autocommit=0的连接在空闲 8 小时后被服务端断开，事务状态仍留在 InnoDB 内部，直到下次被 purge 线程发现并回滚——这段时间它照样占着锁和 undo 空间。
