MySQL 8.0 中最快准定位长事务的方式是查询 performance_schema.events_transactions_current，它比 information_schema.INNODB_TRX 多出当前语句、用户主机、线程ID等关键信息，且比 SHOW PROCESSLIST 更准确反映事务真实生命周期。
怎么快速定位正在运行的长事务
直接查 performance_schema.events_transactions_current 是 MySQL 8.0 最准的方式，比旧版 information_schema.INNODB_TRX 多出当前执行语句、用户主机、线程 ID 等关键信息。别依赖 SHOW PROCESSLIST，它只显示连接状态，不反映事务真实生命周期。
执行这个查询就能看到 Top 10 最长事务：
SELECT thr.processlist_id AS mysql_thread_id,
CONCAT(PROCESSLIST_USER, '@', PROCESSLIST_HOST) AS `User`,
Command,
FORMAT_PICO_TIME(trx.timer_wait) AS trx_duration,
current_statement AS `latest_statement`
FROM performance_schema.events_transactions_current trx
INNER JOIN performance_schema.threads thr USING (thread_id)
LEFT JOIN sys.processlist p ON p.thd_id = thread_id
WHERE thr.processlist_id IS NOT NULL
AND PROCESSLIST_USER IS NOT NULL
AND trx.state = 'ACTIVE'
ORDER BY TIMER_WAIT DESC
LIMIT 10;
- 重点看
trx_duration字段，单位是皮秒，FORMAT_PICO_TIME()会自动转成易读格式（如 “12.34 s”） -
mysql_thread_id是终止事务的唯一依据，别用PROCESSLIST_ID混淆 - 如果
latest_statement是空或NULL，说明事务处于 COMMIT/ROLLBACK 前的等待状态，极可能是应用层卡在业务逻辑里没发提交
哪些 SQL 容易触发长事务陷阱
不是所有慢 SQL 都等于长事务，但以下几类操作一旦包在 START TRANSACTION 里，十有八九会酿成长事务：
-
INSERT ... SELECT扫描大表且没加 LIMIT，尤其跨库或带复杂 JOIN -
UPDATE或DELETE未命中索引，导致全表扫描 + 行锁堆积 - 事务内调用外部服务（HTTP/RPC）、读写文件、sleep() —— 这些操作不占 InnoDB 锁，但拖住整个事务生命周期
- 批量循环执行单条
INSERT/UPDATE，没做分批提交，事务持续时间随数据量线性增长
典型反例：BEGIN; UPDATE orders SET status=1 WHERE created_at < '2025-01-01'; COMMIT; —— 如果 orders 有千万级数据且 created_at 无索引，这条语句本身可能跑 2 分钟，事务就挂了 2 分钟。
终止长事务前必须确认的三件事
别一看到 trx_duration > 60s 就 KILL，误杀业务事务可能引发数据不一致。先验证：
- 查该线程是否还在活跃：用
mysql_thread_id去SHOW FULL PROCESSLIST对应行，看State是否为Query或Commit；如果是Sleep，大概率是应用层已拿到结果但忘了 commit - 确认事务是否已修改关键数据：查
trx_mysql_thread_id关联information_schema.INNODB_TRX的trx_rows_modified，值大于 0 说明有实际变更 - 检查是否有下游依赖：比如该事务关联的微服务请求是否仍在处理中（通过 traceID 或日志回溯），避免 KILL 后上游重试造成重复写入
安全终止命令是：KILL CONNECTION <mysql_thread_id>;（注意是 CONNECTION，不是 QUERY）
从代码层预防长事务比事后排查更有效
DBA 能做的最多是监控和兜底，真正可控的是应用代码。关键控制点：
- 事务边界必须显式声明，禁止“默认开启事务”框架行为（如 Spring 的
@Transactional未设timeout） - 所有事务内非 DB 操作（RPC、缓存更新、日志写入）必须移到事务外，或改用最终一致性方案
- 批量操作强制分页：用
WHERE id BETWEEN ? AND ?替代LIMIT OFFSET，配合 while 循环提交，每次事务控制在 1 秒内 - 设置数据库连接层超时：
innodb_lock_wait_timeout=10（锁等待）+ 应用层spring.transaction.default-timeout=30（事务总时长）
最容易被忽略的是事务传播行为——比如一个标记了 @Transactional 的方法被另一个事务方法调用，默认是 PROPAGATION_REQUIRED，结果两个逻辑被合并进同一个事务，时长翻倍。这种嵌套得靠代码审查，监控工具根本发现不了。
