最有效手段是查 performance_schema.data_lock_waits（8.0+）或 sys.innodb_lock_waits（5.7），需先启用采集、正确关联 innodb_trx，结合 show status 初筛和 prometheus 监控综合判断锁等待根因。
直接查 sys.innodb_lock_waits 或 performance_schema.data_lock_waits 是最有效的实时手段，但必须确认采集已启用、版本匹配，且不能只看单次快照——锁等待是瞬态现象，漏查一秒就可能错过根因。
MySQL 8.0+ 必须用 data_lock_waits，别再查 innodb_lock_waits
在 MySQL 8.0+ 中，INFORMATION_SCHEMA.INNODB_LOCK_WAITS 已被移除，查它永远返回空。你看到的“空结果”不是没锁，而是视图本身不存在了。
- 先确认采集开关是否打开：
SELECT NAME, ENABLED FROM performance_schema.setup_instruments WHERE NAME = 'wait/lock/innoDB/lock';，结果必须为YES - 再开消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'global_instrumentation'; - 查询语句要关联
INNODB_TRX，且必须用trx_id字段连接（不是trx_mysql_thread_id）：SELECT r.trx_id waiting_trx_id, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_query blocking_query FROM performance_schema.data_lock_waits w JOIN information_schema.INNODB_TRX b ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID JOIN information_schema.INNODB_TRX r ON r.trx_id = w.REQUESTING_ENGINE_TRANSACTION_ID;
MySQL 5.7 可用 sys.innodb_lock_waits，但 wait_age_secs 是关键字段
sys.innodb_lock_waits 在 5.7 中仍有效，但它的 wait_started 需手动算时间差，而 wait_age_secs 直接给出已等待秒数，更实用。
- 执行：
SELECT * FROM sys.innodb_lock_waits ORDER BY wait_age_secs DESC LIMIT 5; -
wait_age_secs > 30就该介入——这不是阈值建议，而是经验性异常标志 -
waiting_query为空？说明事务只BEGIN没执行语句，得靠waiting_pid去SHOW PROCESSLIST查Info列 - 结果为空 ≠ 没锁等待：可能是刚释放，或 performance_schema 还没捕获（毫秒级延迟）
Prometheus 监控锁等待频次，只认 innodb_lock_waits_total
别用 mysql_table_lock_waits 或 innodb_row_lock_waits——前者在 8.0+ 里恒为 0，后者是累计值，无法反映实时压力。
- 指标名必须是：
mysql_perf_schema_data_lock_waits_total（mysqld_exporter v0.12.1+） - 启动 exporter 时必须加参数：
--collect.perf-schema.data-lock-waits - PromQL 要用
rate()算频率：rate(mysql_perf_schema_data_lock_waits_total[5m])，而不是直接画原始计数器 - 告警建议用
increase()+ 长窗口：increase(mysql_perf_schema_data_lock_waits_total[1h]) > 100，避免 exporter 重启导致归零误报
别跳过 SHOW STATUS 的初筛，它最快也最轻量
线上卡顿时，第一反应不该是跑复杂 JOIN，而是用权限低、响应快的 SHOW STATUS 快速拍快照。
-
SHOW STATUS LIKE 'innodb_row_lock_current_waits';—— 返回值 > 0 就说明此刻有行锁等待 -
SHOW STATUS LIKE 'innodb_row_lock_time_avg';—— 突然从 0.2ms 跳到 40ms+，基本可断定有慢事务拖累 - 这两个命令普通账号就能执行，不依赖 performance_schema，适合写进自动化巡检脚本
- 注意：
innodb_row_lock_current_waits归零不代表问题消失，可能只是锁刚释放或超时退出（默认innodb_lock_wait_timeout=50）
真正难的不是查到锁，而是判断哪个等待值得干预——比如每秒稳定 2–3 次的等待，比某次批量操作触发的 50 次尖刺更危险；还有那些 trx_query 为空、但 trx_started 是 3 小时前的事务，它们才是沉默的定时炸弹。
