sys.innodb_lock_waits有时查不到正在阻塞的事务，因其依赖performance_schema.data_lock_waits，仅捕获已进入waiting状态且未被快速释放的锁等待，存在1–2秒延迟或瞬时等待漏捕；还需确保相关consumers启用及用户具备必要权限。
sys.innodb_lock_waits 是 MySQL 8.0+ 中最实用的锁阻塞视图，但它不是“实时快照”，而是基于 performance_schema.data_lock_waits 和 INNODB_TRX 的聚合视图。直接查它，容易漏掉刚发生、尚未被清理的瞬时等待。
为什么 sys.innodb_lock_waits 有时查不到正在阻塞的事务？
这个视图底层依赖 performance_schema.data_lock_waits，而后者只记录「当前明确处于 WAITING 状态且已形成阻塞关系」的锁请求；如果阻塞刚发生、事务还没进入 WAITING（比如还在尝试加锁的瞬间），或锁已被快速释放，sys.innodb_lock_waits 就不会体现。
常见误判场景：
- 会话 B 执行
UPDATE t SET x=1 WHERE id=100 FOR UPDATE，但会话 A 持有该行排他锁且未提交 → B 卡住，但sys.innodb_lock_waits可能延迟 1–2 秒才显示 - 会话 A 提交后 B 立即获得锁 → 整个等待过程太短，
sys.innodb_lock_waits根本没来得及捕获 -
performance_schema相关 consumers 未启用（如events_transactions_current、data_locks）→ 视图数据为空
sys.innodb_lock_waits 字段含义与关键过滤条件
它返回的是「谁在等谁」的映射，核心字段包括：
-
waiting_pid：被阻塞线程的 processlist ID（对应SHOW PROCESSLIST中的ID） -
blocking_pid：持有锁并造成阻塞的线程 ID -
locked_table_schema/locked_table_name：锁冲突发生的表 -
waiting_query：被阻塞的 SQL（注意：可能为NULL，尤其当语句已执行完但事务未提交）
实操建议：
- 不要只看
waiting_query，要结合blocking_pid去查INNODB_TRX或sys.session，确认那个线程到底在干啥 - 加
WHERE waiting_pid IS NOT NULL过滤空值（某些版本会返回脏空行） - 用
ORDER BY wait_age DESC（如果视图支持）或按TIME关联PROCESSLIST排序，优先处理等待最久的
必须搭配查的三张基础表
sys.innodb_lock_waits 是“结论”，但排查根源得回溯“证据链”。以下三张表必须联合使用：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
INFORMATION_SCHEMA.INNODB_TRX：看事务状态（TRX_STATE = 'LOCK WAIT'表示正卡着）、开始时间（TRX_STARTED）、SQL（TRX_QUERY） -
performance_schema.data_locks：看每个事务实际持有哪些锁（LOCK_TYPE、LOCK_MODE、INDEX_NAME），尤其是LOCK_DATA字段能定位具体哪一行（如0x0000000000000001） -
sys.session：快速关联线程 ID 和用户、数据库、当前执行语句（current_statement），比PROCESSLIST更结构化
典型联合查询示例：
SELECT w.waiting_pid, w.blocking_pid,
t1.TRX_QUERY AS waiting_sql,
t2.TRX_QUERY AS blocking_sql,
d.LOCK_MODE, d.LOCK_DATA
FROM sys.innodb_lock_waits w
JOIN INFORMATION_SCHEMA.INNODB_TRX t1 ON t1.TRX_ID = w.waiting_trx_id
JOIN INFORMATION_SCHEMA.INNODB_TRX t2 ON t2.TRX_ID = w.blocking_trx_id
JOIN performance_schema.data_locks d ON d.ENGINE_TRANSACTION_ID = w.blocking_trx_id;
容易被忽略的权限与配置前提
即使你用了 MySQL 8.0+，sys.innodb_lock_waits 也可能返回空，原因常是：
- 用户缺少
SELECT权限：至少需要SELECTonperformance_schema.*和information_schema.INNODB_TRX -
performance_schema未启用锁监控：检查setup_consumers中events_transactions_current和data_locks是否为YES - 系统变量
innodb_status_output_locks关闭不影响此视图，但若你后续想用SHOW ENGINE INNODB STATUS辅助验证，建议设为ON（仅调试时）
最简验证命令：
SELECT COUNT(*) FROM performance_schema.data_locks; SELECT COUNT(*) FROM INFORMATION_SCHEMA.INNODB_TRX;
任一返回 0，说明底层数据源缺失，sys.innodb_lock_waits 必然为空。
sys.innodb_lock_waits 显示的那一行里——它只告诉你“谁挡了路”，但不告诉你“为什么这条路非走不可”。索引缺失、事务粒度太大、SQL 访问顺序混乱，这些才是根因。查完视图，务必顺藤摸瓜去看 EXPLAIN 和事务边界。
