应优先查询performance_schema.table_io_waits_summary_by_index_usage中COUNT_READ=0且COUNT_WRITE=0的索引，再结合EXPLAIN、慢日志、应用代码及外键约束综合判断，避免误删；phpMyAdmin仅可辅助识别明显冗余索引。
怎么查出表里那些“挂名不干活”的索引
phpmyadmin 本身不提供“索引使用率”视图，information_schema.statistics 只存定义，不存访问记录。真要识别无效索引，得靠 mysql 的元数据 + 查询日志 + 执行计划交叉验证。
最直接的起点是查 information_schema.INNODB_INDEX_STATS（仅 InnoDB）或更稳妥的 performance_schema.table_io_waits_summary_by_index_usage（MySQL 8.0+）：
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_READ, COUNT_WRITE FROM performance_schema.table_io_waits_summary_by_index_usage WHERE INDEX_NAME != 'PRIMARY' AND COUNT_READ = 0 AND COUNT_WRITE = 0;
这个结果里的索引大概率长期未被查询或写入触发——但注意：COUNT_READ = 0 不等于“绝对没用”，比如只在低峰期执行的报表 SQL 就可能漏掉。
- 必须开启
performance_schema且table_io_waits_summary_by_index_usage消费器已启用（UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_waits_summary_by_index_usage';） - 该统计从实例重启后累计，若数据库刚重启过，所有索引都会显示为 0 —— 别急着删
- 联合索引中部分字段被用到（如
(a,b,c)只用a），仍会记入COUNT_READ；但只用b或c就不会触发，这类“半失效”索引查不到
为什么 EXPLAIN 看不见某些索引却不能断定它无效
常见错觉：在某个 SELECT 上跑 EXPLAIN，发现没走某个索引，就认为它废了。其实 MySQL 选索引是基于成本估算，不是“能不能用”。
比如一张 10 行的测试表，即使建了 INDEX (status)，EXPLAIN SELECT * FROM t WHERE status = 1 也大概率走全表扫描——因为读索引页 + 回表的成本 > 直接扫全表。
立即学习“PHP免费学习笔记（深入）”；
- 索引是否被选中，高度依赖数据分布（如
status只有两个值，区分度太低，优化器会弃用） -
ANALYZE TABLE没及时更新统计信息时，优化器可能误判索引价值 - 隐式类型转换会让索引完全失效（如
WHERE phone = 13800138000，而phone是VARCHAR）——这种“逻辑失效”不会体现在performance_schema统计里
删索引前必须确认的三件事
删错索引比留着慢点更危险。尤其别在没压测的情况下，仅凭“没看到 EXPLAIN 走它”就动手。
- 检查所有应用代码、定时任务、ORM 配置里是否显式指定了
USE INDEX或FORCE INDEX—— 这些语句会绕过优化器决策，强制走某个索引 - 确认该索引是否用于外键约束（
SHOW CREATE TABLE查CONSTRAINT ... FOREIGN KEY ... REFERENCES），删掉会导致 DDL 失败或约束失效 - 在从库上先观察至少一个完整业务周期（比如 24 小时）的慢查询日志，用
mysqldumpslow -s c /var/log/mysql/slow.log看是否有语句因缺失该索引突然变慢
phpMyAdmin 里能做的轻量级辅助判断
虽然 phpMyAdmin 不是分析工具，但能快速暴露明显冗余：
进某张表的 结构 页，看索引列表。重点关注：
- 同字段重复建索引：
INDEX (a)和INDEX (a,b)并存时，前者通常多余（除非有ORDER BY a且不带WHERE的场景） - 前缀索引过长：
INDEX (content(255))建在 TEXT 字段上，但实际查询只匹配前 10 个字符——前缀长度远超必要 - 状态类字段索引：
INDEX (is_deleted)或INDEX (status)，如果值只有 0/1 且占比悬殊（比如 99% 是 0），基本不会被优化器选用，反而拖慢 INSERT/UPDATE
这些一眼可判的“红牌索引”，比纠结统计数字更值得优先处理。真正的难点永远在那些“偶尔有用、多数闲置、删了怕出事”的灰色地带——那里得靠真实流量和足够长的观测窗口说话。
