show engine innodb status 是诊断事务锁和等待问题最直接的现场快照，关键信息在 transactions 和 latest detected deadlock 段，需重点关注 active 超 10 秒事务、lock wait 及 purge 延迟。
如何用 SHOW ENGINE INNODB STATUS 看事务锁和等待
事务性能问题八成出在锁争用或长事务上，SHOW ENGINE INNODB STATUS 是最直接的现场快照。它不采样、不聚合，反映的是执行瞬间的事务状态，但输出冗长，关键信息藏在 TRANSACTIONS 和 LATEST DETECTED DEADLOCK 段里。
实操建议：
- 优先看
Trx id counter和Purge done for trx's n:o —— 如果差值持续增大，说明 purge 线程跟不上，可能拖慢 DML - 找
---TRANSACTION XXX, ACTIVE XXX sec，重点关注ACTIVE时间超过 10 秒的事务，它们大概率没提交或卡在应用层 - 若看到
mysql tables in use 1, locked 1配合LOCK WAIT，基本能定位到哪条 SQL 在等哪把行锁 - 别依赖它查历史——只反映当前时刻，需配合定期抓取脚本（如每 5 秒跑一次并记录时间戳）才能看出趋势
INFORMATION_SCHEMA.INNODB_TRX 查实时事务详情
比 SHOW ENGINE INNODB STATUS 更结构化，适合写监控或排查具体事务 ID。但它只显示已开始、未提交的事务，不会包含刚启动还没执行 SQL 的空事务，也不展示死锁检测逻辑。
实操建议：
- 常用字段：
TRX_ID（内部事务号）、TRX_STATE（RUNNING/LOCK WAIT）、TRX_STARTED（注意是时间戳，不是秒数）、TRX_MYSQL_THREAD_ID（可关联PROCESSLIST） - 查长事务：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60 - 配合
INFORMATION_SCHEMA.INNODB_LOCK_WAITS能定位谁在等谁：REQUESTING_TRX_ID对应TRX_ID，BLOCKING_TRX_ID是持锁方 - 权限注意：需要
PROCESS权限，MySQL 8.0+ 默认关闭information_schema_stats_expiry缓存，结果更准；旧版本可能因统计延迟漏掉短事务
慢查询日志里怎么识别事务开销
默认慢查询日志（slow_query_log）不记录事务控制语句（BEGIN、COMMIT、ROLLBACK），只记 DML/DQL。但事务的真实耗时往往跨多条语句，单条 SQL 慢 ≠ 事务慢，得看整个事务生命周期。
实操建议：
- 开启
log_slow_slave_statements和log_queries_not_using_indexes辅助判断，但核心要打开long_query_time = 0并搭配min_examined_row_limit = 1000过滤噪音 - 关键技巧：在应用层给每个事务加唯一 trace_id（如
/* trx-abc123 */ UPDATE ...），再用正则从慢日志里提取同一 trace_id 下所有语句，计算总耗时 - 注意
SET autocommit = 0后的隐式事务：即使没写BEGIN，第一条 DML 就开启事务，日志里看不到起点，只能靠线程 ID + 时间窗口拼接 - Percona Server 或 MySQL 8.0.26+ 支持
log_slow_extra = ON，会额外记录trx_id和user_host，大幅降低分析成本
为什么 performance_schema 的事务表容易误读
performance_schema.events_transactions_current 理论上能跟踪每个事务，但默认关闭、内存开销大、且事务事件在 COMMIT 或 ROLLBACK 后才写入，无法用于实时阻塞分析——它更适合做“事后归因”，而不是“正在发生什么”。
实操建议：
- 必须先启用：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_transactions_current'，同时确认setup_instruments中transaction相关项已开 - 字段
EVENT_NAME值为transaction，但STATE只有COMMITTED或ROLLED BACK，没有RUNNING状态，所以不能替代INNODB_TRX - 真正有用的是
events_transactions_history_long：它保留最近 10000 条事务记录，可查某次慢响应对应事务里执行了哪些语句、耗时多少、是否回滚 - 最大坑：
performance_schema不记录锁信息，也看不到行锁冲突细节，纯靠它诊断死锁等于蒙眼走路
事务性能评估不是挑一个工具猛刷就行，INNODB_TRX 看现在谁卡着，slow log + trace_id 看过去干了啥，INNODB STATUS 看锁怎么咬上的——三者缺一不可，而且时间窗口要对齐。最容易被忽略的是：应用层事务边界和数据库看到的事务边界经常不一致，比如 ORM 自动重试、连接池复用导致的隐式事务延续，这些都得从客户端日志反推。
