MySQL的索引是提升查询效率的核心组件，但实际业务中经常会出现索引创建后未被使用，或者部分查询没有命中预期索引的情况，因此监控索引使用情况并统计特定查询的执行频率是数据库优化的重要环节。
一、通过performance_schema监控索引使用情况
MySQL自带的performance_schema库提供了丰富的性能监控指标，其中table_io_waits_summary_by_index_usage表可以统计所有索引的IO等待情况，间接反映索引的使用频率。
首先确保performance_schema处于开启状态，执行以下语句查看状态：
-- 查看performance_schema是否开启 SHOW VARIABLES LIKE 'performance_schema';
如果返回值为ON则已经开启，若未开启需要修改MySQL配置文件重启服务。开启后可以通过以下语句查询指定表的索引使用情况：
-- 查询test库下user表的索引使用情况
SELECT
OBJECT_NAME AS 表名,
INDEX_NAME AS 索引名,
COUNT_READ AS 读取次数,
COUNT_WRITE AS 写入次数,
COUNT_FETCH AS 获取行数
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE OBJECT_SCHEMA = 'test'
AND OBJECT_NAME = 'user'
AND INDEX_NAME IS NOT NULL;
其中COUNT_READ数值越高说明该索引被查询使用的频率越高，如果某个索引的COUNT_READ长期为0，说明该索引可能属于冗余索引，可以考虑删除。
二、编写触发器记录特定查询频率
如果需要统计某类特定查询的执行频率，比如统计查询user表中年龄大于30岁的用户操作的执行次数，可以通过创建日志表和触发器实现。
2.1 创建查询记录表
首先创建一个用于存储查询记录的表，记录查询执行的时间和类型：
-- 创建查询频率记录表
CREATE TABLE IF NOT EXISTS query_frequency_log (
id INT PRIMARY KEY AUTO_INCREMENT,
query_type VARCHAR(50) NOT NULL COMMENT '查询类型标识',
execute_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '执行时间'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='特定查询执行频率记录表';
2.2 创建触发器
假设我们需要统计执行SELECT * FROM user WHERE age > 30这类查询的频率，由于MySQL的触发器是基于表操作触发的，我们可以在该查询对应的表上创建AFTER SELECT触发器吗？实际上MySQL不支持AFTER SELECT触发器，因此我们可以换一种思路，在user表的SELECT操作前通过应用层配合，或者如果是针对特定条件的更新类操作，可以创建对应触发器。这里以统计user表的查询操作为例，结合performance_schema的语句监控，同时我们可以通过触发器记录针对user表的写操作触发的关联查询频率：
-- 创建触发器，在user表插入数据后记录关联查询频率
DELIMITER //
CREATE TRIGGER tr_user_insert_after
AFTER INSERT ON user
FOR EACH ROW
BEGIN
-- 记录插入操作触发的关联查询统计
INSERT INTO query_frequency_log (query_type) VALUES ('user_insert_related_query');
END //
DELIMITER ;
如果是需要统计纯查询语句的频率，更推荐的方式是在应用层执行查询前，同时向query_frequency_log表插入记录，或者通过MySQL的审计插件实现，触发器更适合记录表操作关联的查询场景。
2.3 查询统计结果
通过以下语句可以统计指定查询类型在一段时间内的执行频率：
-- 统计最近7天user_insert_related_query类型的查询频率
SELECT
DATE(execute_time) AS 统计日期,
COUNT(*) AS 执行次数
FROM query_frequency_log
WHERE query_type = 'user_insert_related_query'
AND execute_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DATE(execute_time)
ORDER BY 统计日期 DESC;
三、两种监控方式的对比
两种方式各有适用场景，具体差异如下：
| 监控方式 | 优势 | 局限性 |
|---|---|---|
| performance_schema监控 | 无需额外创建表，直接获取所有索引的使用统计，数据准确 | 只能统计索引级别的IO情况，无法精确到某类特定查询 |
| 触发器记录 | 可以自定义统计特定查询或操作的频率，灵活度高 | MySQL不支持SELECT触发器，纯查询统计需要应用层配合，会增加少量写入开销 |
四、注意事项
- performance_schema的统计数据会在MySQL重启后清空，如果需要长期留存数据，需要定期将统计结果备份到其他表。
- 触发器会增加表操作的额外开销，不要在高频操作的表上创建过多复杂触发器，避免影响业务性能。
- 索引监控需要结合业务场景分析，不能仅根据使用次数就删除索引，比如部分低频但重要的查询如果缺少索引会导致全表扫描，影响业务可用性。
MySQL索引监控触发器查询频率performance_schema修改时间：2026-07-22 05:06:24