如何在phpMyAdmin中识别未被使用的无效索引_辅助数据库减负的元数据分析-phpMyAdmin-PHP中文网

应优先查询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 也大概率走全表扫描——因为读索引页 + 回表的成本 > 直接扫全表。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

索引是否被选中，高度依赖数据分布（如 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

这些一眼可判的“红牌索引”，比纠结统计数字更值得优先处理。真正的难点永远在那些“偶尔有用、多数闲置、删了怕出事”的灰色地带——那里得靠真实流量和足够长的观测窗口说话。