MySQL无法用触发器监控索引使用，因触发器仅响应DML事件，不感知SELECT；必须组合使用EXPLAIN（查执行计划）、performance_schema.table_io_waits_summary_by_index_usage（看COUNT_FETCH频次）和开启log_queries_not_using_indexes的慢查询日志。
MySQL 本身不提供触发器机制来监控索引使用情况——这是个常见误解。触发器响应的是 INSERT、UPDATE、DELETE 这类 DML 事件，而索引是否被使用，发生在查询执行计划阶段（SELECT），不产生可被触发的行级变更事件。试图用触发器“记录某条 SELECT 被执行了多少次”在 MySQL 中不可行。
下面直接说清楚该怎么做、为什么不能绕开、以及最容易栽跟头的地方。
为什么不能用触发器监控索引使用
触发器本质是表级 DML 副作用钩子，它对 SELECT 完全无感：
- SELECT 不修改数据，不触发任何 BEFORE/AFTER 触发器
- 即使你给目标表建了 10 个触发器，执行 EXPLAIN SELECT ... 或实际查询时，它们一个都不会动
- 没有 ON SELECT 触发器语法，MySQL 不支持，也不打算支持
真正能监控索引使用的三类手段
必须组合使用，缺一不可：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
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
INCRkey） - 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 是过期估算，会导致优化器误判
