如何通过编写MySQL触发器监控并记录特定查询的高频使用索引？

本文共计788个文字，预计阅读时间需要4分钟。

MySQL 本身不提供触发器机制来监控和控制索引的使用情况。这是一种常见误解。触发器响应的是如下 DML 事件：

下面直接说清楚该怎么做、为什么不能绕开、以及最容易栽跟头的地方。

为什么不能用触发器监控索引使用

触发器本质是表级 DML 副作用钩子，它对 SELECT 完全无感：
- SELECT 不修改数据，不触发任何 BEFORE/AFTER 触发器
- 即使你给目标表建了 10 个触发器，执行 EXPLAIN SELECT ... 或实际查询时，它们一个都不会动
- 没有 ON SELECT 触发器语法，MySQL 不支持，也不打算支持

真正能监控索引使用的三类手段

必须组合使用，缺一不可：

• EXPLAIN：查单条 SQL 是否走索引。重点盯 key（非 NULL）、type（避开 ALL）、key_len（是否只用了联合索引前缀）
• performance_schema.table_io_waits_summary_by_index_usage：看运行时真实调用频次。COUNT_FETCH = 0 的索引大概率是僵尸索引，但需确认 performance_schema 已启用且相关 consumers 开启（如 events_statements_history_long）
• 慢查询日志 + log_queries_not_using_indexes = ON：这是兜底项。没走索引的慢查会进日志，否则你根本发现不了那些“理论上能走、实际上没走”的语句

想统计“某查询执行次数”？用替代方案

如果目标其实是记录某个业务查询（比如“用户登录校验”）被调用了多少次，不要碰触发器，改用：

• 应用层埋点：在 DAO 层或 ORM 执行前加计数（如 Redis INCR key）
• MySQL user_stats（需启用 userstat = ON）+ SHOW PROCESSLIST 抓关键词，但精度低、开销大
• Proxy 层拦截（如 ProxySQL、MaxScale）：在 SQL 流量入口做匹配和计数，不影响 MySQL 内核

硬要在 MySQL 内部实现，唯一可行的是创建一个“查询日志表”，再靠外部工具（如 pt-query-digest）解析慢日志后写入——但这和触发器无关，也绝非实时。

容易被忽略的关键点

很多人查完 performance_schema 表就以为万事大吉，但忘了：
- 该表统计从实例启动或上次 TRUNCATE 后的累计值，不是实时速率；长期观察必须定期快照取差值
- COUNT_FETCH = 0 只说明没被读取过，但可能是低频核心查询（如财务对账），删之前必须结合业务确认
- ANALYZE TABLE 必须手动执行，否则 information_schema.STATISTICS.CARDINALITY 是过期估算，会导致优化器误判