Grafana中锁等待趋势依赖mysql_innodb_lock_waits指标，该指标由MySQL Exporter采集自Performance Schema，反映单位时间锁等待事件次数而非时长；需启用对应采集器和锁监控仪器，并结合SHOW ENGINE INNODB STATUS做实时诊断，告警应基于同比/环比变化率而非绝对阈值。
Grafana 里看锁等待趋势，核心指标是 mysql_innodb_lock_waits
这个指标不是 MySQL 原生暴露的，而是由 Prometheus 的 MySQL Exporter（如 percona/mysqld_exporter）采集后上报的。它本身不直接表示“等待时长”，而是统计单位时间内发生的锁等待事件次数。真正反映等待严重程度的是 mysql_innodb_lock_wait_time_total（总等待时间）和 mysql_innodb_lock_wait_time_seconds_sum（需确认 exporter 版本是否支持该指标名），但绝大多数生产环境用的是前者 + 趋势斜率来判断恶化节奏。
常见错误现象：在 Grafana 里搜不到 mysql_innodb_lock_waits，或曲线始终为 0 —— 大概率是 MySQL Exporter 没启用 InnoDB 锁相关采集器，或 MySQL 未开启 Performance Schema 的锁监控。
- 检查 exporter 启动参数是否含
--collect.perf_schema.eventswaits或类似锁采集开关 - 确认 MySQL 中 Performance Schema 的锁 instruments 已启用：
SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE '%lock%'，结果中ENABLED应为YES - 部分老版本 exporter 不采集锁等待计数，建议升级到 v0.15.0+ 并使用官方推荐配置
SHOW ENGINE INNODB STATUS 和 Grafana 不是替代关系，而是互补
Grafana 提供的是宏观趋势（比如过去 1 小时每分钟锁等待激增 300%），SHOW ENGINE INNODB STATUS 给的是快照级现场（谁在等、等什么、谁在持锁）。两者必须配合使用：看到 Grafana 曲线尖峰，立刻执行该命令查 TRANSACTIONS 段，重点关注带 WAITING FOR THIS LOCK TO BE GRANTED 的事务。
容易踩的坑是只盯 Grafana 图表，忽略实时诊断。例如某次线上故障，Grafana 显示 mysql_innodb_lock_waits 每秒 8 次，但 SHOW ENGINE INNODB STATUS 显示只有 1 个事务在等，说明是短平快的高频冲突（如秒杀扣库存），而非长事务阻塞；反之，若 Grafana 数值不高但持续存在，而 innodb_trx 里有 trx_started 超过 5 分钟的记录，则大概率是长事务拖住锁资源。
构建有效告警，不能只看绝对值
锁等待次数本身没有固定阈值。设成“>5 次/秒”就告警，会误报；设成“>100 次/秒”又可能漏掉早期征兆。真正有用的策略是监控同比/环比变化率：
- 过去 5 分钟平均值 vs 过去 1 小时平均值，上涨 >200% 触发 P2 告警
- 连续 3 个采集周期（如每 15 秒采一次）数值 > 阈值（建议基线设为近 7 天 P95 值），触发 P1 告警
- 同时叠加
mysql_threads_connected和mysql_innodb_row_lock_time_avg，避免把连接数暴涨误判为锁问题
别忘了加维度过滤：用 instance 标签区分主从，用 job 区分不同业务库。一个电商库的锁等待飙升，不该触发支付库的告警。
Performance Schema 是 Grafana 数据源头，但开销不可忽视
启用 wait/lock/% 类型的 instruments 会带来约 3–8% 的 CPU 开销（视并发量而定），尤其在高 QPS 场景下。不是所有锁事件都需要采集 —— 生产环境建议只开关键项：
-
wait/lock/table/sql/handler（表级锁，通常是索引失效导致） -
wait/lock/inno_db/row_lock（行锁，最常关注） -
wait/lock/metadata/sql/mdl（MDL 锁，DDL 操作引发）
禁用 wait/lock/synch/mutex 等底层同步锁，它们对业务影响小且噪音大。改完记得重启 exporter 并验证指标是否正常上报 —— 最简单方式是 curl 一下 exporter 的 /metrics 接口，搜索 mysql_innodb_lock_waits 是否出现。
真正难的是把 Grafana 图表和具体 SQL 关联起来。指标能告诉你“哪里堵了”，但不会告诉你“为什么堵”。每次锁等待尖峰后，必须回溯当时 information_schema.INNODB_TRX 和 sys.innodb_lock_waits 的快照，否则监控就只是好看的数据画布。
