确认事务本身慢需查 performance_schema.events_transactions_history_long 表（开启对应 consumer 和 instrument），或用 information_schema.INNODB_TRX 查真实运行时长；SHOW PROCESSLIST 无法反映空闲事务，因状态为 Sleep；innodb_lock_wait_timeout 仅控制锁等待超时，不影响事务自身执行慢。
怎么确认是事务本身慢，而不是某条SQL慢
慢查询日志默认只记录单条语句的执行时间，long_query_time 触发条件对事务整体无效。一个事务里可能有5条语句，每条都不到1秒，但加起来卡了10秒——这种“事务级延迟”不会进慢日志。
真正能抓到事务耗时的，是 performance_schema.events_transactions_history_long 表（MySQL 5.6+ 默认关闭）：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_transactions_history_long';
之后再查：
SELECT EVENT_ID, TRX_ID, TIMER_WAIT/1000000000 AS sec, STATE, GTID FROM performance_schema.events_transactions_history_long WHERE TIMER_WAIT > 5000000000 ORDER BY TIMER_WAIT DESC LIMIT 5;
-
TIMER_WAIT单位是皮秒，除以1000000000得秒级数值 -
STATE = 'COMMITTED'或'ROLLED BACK'是已结束事务；'ACTIVE'是还在跑的，要结合processlist看 - 如果查不到记录，大概率是
setup_consumers没开，或者setup_instruments里transaction相关项被禁用了
为什么 SHOW PROCESSLIST 看不到长时间运行的事务
因为事务可能处于“空闲等待”状态：比如应用层开启事务后，没提交也没回滚，就挂在那里等业务逻辑继续——此时线程状态是 Sleep，不是 Query 或 Updating，SHOW PROCESSLIST 只显示连接状态，不反映事务生命周期。
必须用 information_schema.INNODB_TRX 查真实事务：
SELECT trx_id, trx_started, NOW() - trx_started AS duration_sec, trx_state, trx_mysql_thread_id FROM information_schema.INNODB_TRX ORDER BY duration_sec DESC LIMIT 5;
-
trx_state = 'RUNNING'不代表正在执行SQL，可能是刚执行完一条，正等着下一条 -
trx_mysql_thread_id可以和PROCESSLIST的ID关联，找到对应连接的USER和HOST - 注意
trx_started是事务开始时间，不是连接建立时间——很多误以为“连接太久=事务太久”，其实连接可能复用，事务才刚启
innodb_lock_wait_timeout 和实际事务卡顿没关系
这个参数只控制“等锁超时”，比如A事务锁了某行，B事务想改同一行，B最多等50秒（默认值）就报错 Lock wait timeout exceeded。但它完全不影响“事务自己慢慢跑”的情况。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
真正影响长事务感知的，是下面两个配置：
-
innodb_rollback_on_timeout = OFF（默认）：等锁超时后，事务不会自动回滚，而是继续挂着——这会让INNODB_TRX里出现一堆“假活跃”事务 -
wait_timeout和interactive_timeout：控制空闲连接断开时间，但对已开启事务的连接无效；事务里的连接哪怕空闲2小时，只要没提交，就不会被踢 - 所以别指望调小
innodb_lock_wait_timeout来“缩短事务时间”，它只管锁争用，不管业务逻辑卡在哪
从应用侧定位事务慢的常见盲区
DBA看到 INNODB_TRX 里有个事务跑了8分钟，第一反应是查SQL，但往往问题出在应用没发SQL——比如Java里用 @Transactional 包了一大段HTTP调用、文件读写、循环计算，事务从 begin 开始就卡在应用层，数据库根本没收到第二条命令。
这时候 performance_schema.events_statements_history 里可能只有一条 BEGIN，后面全是空的。
- 检查应用日志里事务开始和提交之间有没有非DB操作（尤其是远程调用、sleep、重试逻辑）
- Spring Boot 中
@Transactional(timeout = 30)设置的是JDBC层超时，不是数据库事务超时；如果底层连接池（如HikariCP）没配connection-timeout，事务可能一直挂着 - Python 的
with conn.cursor() as cur:不等于事务边界；得看是不是显式调了conn.begin()或用了上下文管理器包装了整个事务块
事务慢的根因，八成不在MySQL配置里，而在“谁在控制事务生命周期”这件事上没理清。数据库只是执行者，不是调度者。
