判断长事务需查INNODB_TRX表，用UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(trx_started)计算秒数，超60秒预警、超300秒干预；trx_state='RUNNING'未必真执行，Sleep状态且Time>0需联查PROCESSLIST确认；KILL thread_id可终止线程并触发隐式回滚（autocommit=OFF时），但KILL QUERY仅停语句不结束事务。
怎么判断一个事务是不是“长事务”
MySQL里没有叫“长事务”的官方类型，它只是指那些持续时间远超业务正常预期的事务。关键看两个指标：trx_started 和 trx_state，不是看 trx_duration（这个字段根本不存在）。
查 information_schema.INNODB_TRX 表时，用 UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(trx_started) 算出秒数，超过 60 秒就该盯一眼，超过 300 秒基本要干预。
- 要注意
trx_state = 'RUNNING'不代表真在执行 SQL，可能是应用拿了连接没提交，卡在应用层 -
trx_operation_state为空或'starting index read'这类停滞状态，比'fetching rows'更可疑 - 如果
trx_mysql_thread_id对应的PROCESSLIST里Command是Sleep，那基本就是应用忘了COMMIT或ROLLBACK
kill 命令能直接干掉事务吗
不能直接 kill 事务，只能 kill 线程（即 mysql_thread_id）。事务是否回滚，取决于 kill 后 MySQL 是否来得及做清理。
- 对
Command = 'Sleep'的线程执行KILL <code>thread_id，MySQL 会立即断开连接，触发隐式回滚（前提是 autocommit=OFF） - 对正在执行
UPDATE或INSERT的线程，KILL发出后，语句会中断，但事务仍处于ACTIVE状态，直到连接关闭才回滚 - 千万别用
KILL QUERY <code>thread_id—— 它只终止当前语句，不结束事务，反而可能让事务卡得更久
示例：
KILL 12345;不是
KILL QUERY 12345，也不是 KILL CONNECTION 12345（效果同 KILL，但语义冗余）。
监控 processlist 时容易漏掉的三类长事务
SHOW PROCESSLIST 只显示连接级信息，和 INNODB_TRX 不完全对齐。以下情况容易误判：
- 应用使用连接池（如 HikariCP），线程 ID 复用快，
PROCESSLIST里看到的是新查询，但背后事务还是老的 —— 必须联查INNODB_TRX+PROCESSLIST -
Command = 'Sleep'且Time > 0的线程，如果INNODB_TRX里有对应记录，就是长事务；但如果trx_state = 'COMMITTING'，说明正在刷日志，此时 kill 可能导致 crash-safe 机制介入，需谨慎 - 使用了 XA 事务的线程，在
PROCESSLIST里Command显示为Sleep，但在INNODB_TRX里trx_state = 'PREPARED'—— 这种必须人工确认，不能直接 kill，否则可能破坏分布式一致性
自动清理脚本里最常写错的条件
写定时脚本查杀长事务时，很多人用 Time > 300 来过滤 PROCESSLIST，这完全无效：因为 Time 是连接空闲时间，不是事务持续时间。
- 正确做法是 JOIN
INNODB_TRX和PROCESSLIST，用trx_started算真实时长 - 别漏掉
WHERE trx_state != 'COMMITTED'，已提交的事务不该进清理范围 - 杀之前加
AND trx_started < DATE_SUB(NOW(), INTERVAL 5 MINUTE)，避免刚启动的事务被误伤 - 生产环境务必加
AND trx_mysql_thread_id NOT IN (SELECT id FROM performance_schema.threads WHERE TYPE = 'BACKGROUND')，排除内部线程（如 purge、buffer pool dump）
复杂点在于：事务可能跨多个连接（比如中间件复用连接），也可能被复制线程阻塞。这些没法靠单次 KILL 解决，得结合 innodb_lock_waits 和 replication_applier_status_by_coordinator 综合判断。
