mysql索引使用情况需通过explain、performance_schema和handler_read_*状态变量综合分析：explain看单条sql是否走索引；performance_schema.table_io_waits_summary_by_index_usage查索引访问频次；handler_read_key/(handler_read_key+handler_read_rnd_next)估算全局命中率。
phpEnv 本身不提供索引使用率的直接查看能力——它只是 Windows 下集成 Nginx + PHP + MySQL 的环境套件，底层 MySQL 的索引监控仍需靠原生 MySQL 机制。真正能查“索引用没用上”“用了多少次”的，只有 MySQL 自身的 performance_schema、EXPLAIN 和状态变量。
怎么查某个 SQL 实际走了哪个索引（必须用 EXPLAIN）
别信 phpEnv 界面里“索引已建”的提示，那只是结构存在。真正是否生效，得对具体查询加 EXPLAIN：
-
type字段是 ALL 或 index → 实际在全表或全索引扫描，索引没起到过滤作用 -
key非 NULL 但key_len比预期小 → 可能只用了联合索引的前缀，比如索引是(a,b,c)，但查询只写了WHERE a = 1，key_len就不会覆盖全部三列 -
Extra出现Using filesort或Using temporary→ 即使key有值，ORDER BY 或 GROUP BY 也没走索引，得检查字段顺序是否匹配索引定义
怎么查所有索引的长期使用频次（performance_schema.table_io_waits_summary_by_index_usage）
这是目前唯一能反映“这个索引上线后到底有没有被查过”的运行时指标，但需手动启用相关采集器：
- 确认
performance_schema已开启：SHOW VARIABLES LIKE 'performance_schema';返回 ON 才有效 - 启用等待事件采集：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_waits_current'; - 启用表级 I/O 仪器：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'wait/io/table/%'; - 查真实访问次数：
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_FETCH FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema') AND COUNT_FETCH = 0;——COUNT_FETCH = 0的非主键索引，基本就是“幽灵索引”
怎么算全局索引命中率（Handler_read_* 状态变量）
这不是精确命中率，而是存储引擎层读取行为的粗略比值，适合快速判断是否存在大面积全表扫描：
- 执行
SHOW STATUS LIKE 'Handler_read%'; - 重点关注两个值：
Handler_read_key（通过索引定位行的次数）和Handler_read_rnd_next（全表扫描读行次数） - 估算公式：
Handler_read_key / (Handler_read_key + Handler_read_rnd_next) * 100%，低于 90% 就该警惕 - 注意：
Handler_read_first高但Handler_read_key低 → 很可能是SELECT *加ORDER BY扫了整个索引，却没带 WHERE 条件，这种不算有效索引使用
phpEnv 环境下容易被忽略的坑
Windows + phpEnv 的默认配置常埋雷：
- MySQL 5.7+ 默认
performance_schema是开的，但 instruments 和 consumers 多数为 OFF，不手动开就等于没开 - phpEnv 自带的 MySQL 配置文件（如
my.ini）里通常没开log_queries_not_using_indexes，漏掉这条，慢查询日志就捕不到“没走索引”的语句 -
ANALYZE TABLE必须手动执行，phpEnv 不会自动刷新information_schema.STATISTICS中的CARDINALITY，基数不准会导致优化器选错索引 - Windows 下 MySQL 的
slow_query_log_file路径若含中文或空格（比如C:\phpEnv\服务端\MySQL\logs\slow.log），日志可能写失败且无报错，建议改用纯英文路径
最麻烦的点其实是：同一个索引，在不同查询里可能一部分走、一部分不走；而 performance_schema 统计的是累计值，重启就清零。真要判断一个索引能不能删，得至少观察一周业务高峰时段的 COUNT_FETCH 变化，而不是看某次查询结果。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
