如何解决MySQL长事务导致的性能问题-mysql教程-PHP中文网

mysql 8.0 中最快准定位长事务的方式是查询 performance_schema.events_transactions_current，它比 information_schema.innodb_trx 多出当前语句、用户主机、线程id等关键信息，且比 show processlist 更准确反映事务真实生命周期。

如何解决mysql长事务导致的性能问题

怎么快速定位正在运行的长事务

直接查 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 —— 如果 <code>orders 有千万级数据且 created_at 无索引，这条语句本身可能跑 2 分钟，事务就挂了 2 分钟。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

终止长事务前必须确认的三件事

别一看到 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>;</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，结果两个逻辑被合并进同一个事务，时长翻倍。这种嵌套得靠代码审查，监控工具根本发现不了。