performance schema 中记录行级锁信息的核心表是 events_waits_history_long 和 events_waits_summary_by_thread_by_event_name，配合 information_schema.innodb_trx 与 innodb_lock_waits 联查可定位阻塞链；需启用 setup_instruments 中的 wait/innodb/innodb_lock_wait 及对应 consumers 才能捕获。
Performance Schema 中哪些表记录行级锁信息
MySQL 5.7+ 的 performance_schema 并不直接暴露“行级锁”本身（InnoDB 行锁是内存结构，不持久化），但会记录与之强相关的等待事件：wait/innodb/innodb_lock_wait 和更底层的 wait/synch/mutex/innodb/...。真正反映行锁争用的核心表是：
-
performance_schema.events_waits_history_long：默认保留 10,000 条最近等待事件，含完整堆栈和时长 -
performance_schema.events_waits_summary_by_thread_by_event_name：按线程+事件聚合统计，适合发现高频锁等待类型 -
information_schema.INNODB_TRX和INNODB_LOCK_WAITS：虽不属于 Performance Schema，但必须联查——INNODB_LOCK_WAITS能直接告诉你哪个事务在等哪个事务的哪把锁
注意：setup_consumers 中必须启用 events_waits_history_long 和 events_waits_current，否则查不到实时等待；setup_instruments 中需开启 wait/innodb/innodb_lock_wait（默认关闭）。
如何实时抓取正在发生的行锁等待
用以下查询可立刻看到当前阻塞链（谁在等谁、等了多久、SQL 是什么）：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query, TIMESTAMPDIFF(SECOND, r.trx_started, NOW()) wait_time_sec FROM information_schema.INNODB_TRX r INNER JOIN information_schema.INNODB_LOCK_WAITS w ON r.trx_id = w.requesting_trx_id INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id;
这个结果比 Performance Schema 更直接，因为它是 InnoDB 层的原生视图。但缺点是只显示“已形成阻塞”的情况，对瞬时、未升级为阻塞的锁竞争（如多个事务快速抢同一行）捕获不到——这时就得靠 events_waits_history_long 查 wait/innodb/innodb_lock_wait 事件。
为什么查不到 wait/innodb/innodb_lock_wait 事件
这是最常踩的坑：该 instrument 默认处于 DISABLED 状态，且不会自动开启。执行以下两步缺一不可：
- 更新 instruments 表：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'wait/innodb/innodb_lock_wait'; - 确认对应 consumer 已启用：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_waits_current', 'events_waits_history_long');
修改后新连接才会生效，已有连接的等待事件不会回填。另外，该事件仅在事务实际进入锁等待（即调用 row_lock_wait）时触发，普通 SELECT 不加锁、INSERT 不冲突、UPDATE 无并发修改都不会产生此事件。
从 Performance Schema 定位热点行锁对象
如果想定位“哪些表/索引被频繁争抢”，不能只看事务 SQL，得结合 events_waits_history_long 的 OBJECT_SCHEMA、OBJECT_NAME 和 INDEX_NAME 字段：
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT(*) cnt, AVG(TIMER_WAIT)/1000000000 avg_wait_sec, MAX(TIMER_WAIT)/1000000000 max_wait_sec FROM performance_schema.events_waits_history_long WHERE EVENT_NAME = 'wait/innodb/innodb_lock_wait' AND OBJECT_SCHEMA IS NOT NULL GROUP BY OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME ORDER BY cnt DESC LIMIT 5;
这里的关键是 INDEX_NAME —— 行锁总是加在索引记录上。如果 INDEX_NAME 是 PRIMARY，说明争用集中在主键；如果是二级索引名，说明是通过该索引定位行时产生的锁竞争。没有 INDEX_NAME 值？那可能是全表扫描或隐式锁升级导致，需要进一步检查执行计划。
真正难的是区分“业务逻辑导致的合理争用”和“设计缺陷引发的锁放大”。比如高频更新同一张配置表的单行，或者用非唯一字段做 UPDATE WHERE 条件导致锁住多行——这些不会直接报错，但会在 events_waits_history_long 里留下密集的、相同 OBJECT_NAME + INDEX_NAME 的等待记录。
