MySQL无法通过存储过程监控未走索引的慢查询，因为存储过程在SQL执行后运行，不参与优化阶段，也无法拦截或修改SELECT语句；唯一内核支持的方式是启用log_queries_not_using_indexes配合slow_query_log和合理long_query_time。
MySQL 中无法通过存储过程监控未走索引的慢查询——这不是能力问题，而是架构限制：存储过程运行在 SQL 执行之后，它不参与查询优化阶段，也无法拦截或重写已发出的 SELECT 语句。
为什么存储过程做不到这件事
- 存储过程本质是预编译的 SQL 逻辑块，调用时才执行；它对“某条外部
SELECT是否走了索引”完全不可见 - 没有钩子能让你在
EXPLAIN阶段介入，更无法修改优化器决策 - 即使你在存储过程中写
EXPLAIN SELECT ...，那只是对一条静态语句做计划分析，不是实时捕获线上所有查询行为 - 所有 DML 触发器、存储过程、函数，都不感知 SELECT 的执行路径选择
真正可用的监控路径（必须组合）
log_queries_not_using_indexes 是唯一由 MySQL 内核直接支持的“未走索引即记录”机制，但它依赖且仅依赖以下条件：
-
slow_query_log = ON（必须开启，否则该选项无效） -
long_query_time设置合理（例如0.1，否则快但无索引的查询会被跳过） - 日志路径可写、配置位于
[mysqld]段（不是[client]）
验证是否生效的最小闭环：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 0.1; SET GLOBAL log_queries_not_using_indexes = ON; -- 然后执行： SELECT * FROM users WHERE nickname = 'abc'; -- 假设 nickname 无索引
再检查 slow_query_log_file 是否新增了这条记录。没有，就一定是配置没生效或权限/路径问题。
如果非要“在 MySQL 内部”做点事，能做什么？
你可以在 MySQL 里建一张日志表，再靠外部工具把慢日志内容解析后写入——但这和存储过程无关：
- 创建表：
CREATE TABLE slow_query_log_archive (...) - 用
pt-query-digest --filter '$event->{Bytes} > 1024' --execute ...或定时脚本解析日志并INSERT - 若坚持用存储过程，只能作为“归档清洗逻辑”的一部分（比如去重、格式标准化），绝不能用于捕获或判定“是否走索引”
真正容易被忽略的一点：log_queries_not_using_indexes 记录的是优化器实际放弃索引的行为，不是“字段没索引就记”。哪怕你给 name 加了索引，只要写了 WHERE UPPER(name) = 'ABC'，它依然会进日志——因为函数导致索引失效。这个细节决定了你看到的日志条目，往往暴露的是 SQL 写法问题，而不是建索引的疏漏。
