mysql 8.0中需监控wait/synch/mutex/innodb/*类互斥锁（如buf_pool_mutex、log_sys_mutex），而非不存在的“lock sys”；须启用performance_schema、开启对应instruments，并通过events_waits_history_long等表定位高耗时锁及根因sql。
MySQL 8.0 中没有叫 Lock sys 的互斥量，这是常见误读——实际要监控的是 wait/synch/mutex/innodb/* 类内核级互斥锁（如 buf_pool_mutex、log_sys_mutex），它们反映 InnoDB 存储引擎内部资源争用，而非系统表或 sys 库本身的锁。
确认 performance_schema 已启用且采集器就位
所有 wait_events 数据都依赖 performance_schema，它默认开启但常被生产环境手动关闭。不检查这步，后续查询全为空。
- 运行
SELECT VARIABLE_VALUE FROM performance_schema.setup_consumers WHERE NAME = 'global_instrumentation';，若返回NO，需先执行UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'global_instrumentation'; - 同步启用 mutex/rwlock 采集：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'wait/synch/mutex/%' OR NAME LIKE 'wait/synch/rwlock/%'; -
performance_schema_events_waits_history_long_size默认仅 10000 条，高并发下易被覆盖，建议设为1000000以保留足够等待样本
查高频/高延迟的 InnoDB mutex 事件
真正影响性能的是那些被反复争抢、单次等待又长的锁。只看“谁在等”没用，得聚焦“哪把锁最烫手”。
- 按总耗时排序前 10 名 mutex：
SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT, SOURCE FROM performance_schema.events_waits_history_long WHERE EVENT_NAME LIKE 'wait/synch/mutex/innodb/%' GROUP BY EVENT_NAME ORDER BY SUM_TIMER_WAIT DESC LIMIT 10; - 查当前正在卡住的线程（等待超 1 秒）：
SELECT THREAD_ID, EVENT_NAME, TIMER_WAIT, SOURCE, OBJECT_NAME FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE 'wait/synch/mutex/innodb/%' AND TIMER_WAIT > 1000000000; - 典型高危锁：
wait/synch/mutex/innodb/buf_pool_mutex（缓冲池争用）、wait/synch/mutex/innodb/log_sys_mutex（redo 日志系统瓶颈），它们直接对应 buffer pool 太小或 commit 频率过高
关联 threads 和 statements 定位根因 SQL
光知道锁名不够，必须追到具体是哪个线程、哪条 SQL 在高频触发争用。否则优化无从下手。
- 用
THREAD_ID关联performance_schema.threads查PROCESSLIST_ID和用户信息 - 再连
performance_schema.events_statements_history（需确保该 consumer 已开）查最近执行语句：SELECT SQL_TEXT FROM performance_schema.events_statements_history WHERE THREAD_ID = ? ORDER BY EVENT_ID DESC LIMIT 1; - 注意：
events_statements_history默认每线程只存 10 条，若 SQL 执行快、频率低，可能已被覆盖；此时需调大performance_schema_events_statements_history_size
mutex 争用本质是热点资源串行化瓶颈，不是 SQL 写得差就能解决的。比如 buf_pool_mutex 高频出现，说明要么 buffer pool 过小被迫频繁刷脏页，要么业务存在大量非顺序写入——这时候看慢查询没用，得调配置或改数据分布模式。
