用pt-duplicate-key-checker可精准识别重复/冗余索引，如idx_email与idx_email_status_created中前者被后者前缀覆盖；需通过命令如pt-duplicate-key-checker --database db_name --user root --password 'xxx'执行，并人工验证索引实际使用情况后再删除。
怎么用 pt-duplicate-key-checker 找重复索引
phpmyadmin 本身不提供检测重复索引的功能，它只负责执行 sql 或展示结构。真要查冗余索引，得靠外部工具——pt-duplicate-key-checker 是最直接、最可靠的方案。
它能识别出「一个索引完全被另一个索引覆盖」的情况，比如 idx_last_name（单列）和 idx_last_name_first_name（复合），前者就是冗余的。
- 安装后运行命令：
pt-duplicate-key-checker --database db_name --user root --password 'xxx' - 输出会明确标出哪几个索引重复，以及谁是「被覆盖者」
- 注意：必须有对应数据库的 SELECT 权限，且工具连接的是 MySQL 实例，不是 phpMyAdmin 界面
为什么 SHOW INDEX FROM table_name 不够用
SHOW INDEX FROM table_name 只列出索引名和字段顺序，但不会告诉你这些索引之间是否存在包含关系。人眼比对容易漏判，尤其当索引字段多、命名不规范时。
例如这两个索引都存在：
KEY `idx_email` (`email`), KEY `idx_email_status_created` (`email`, `status`, `created_at`)
表面上看字段不同，但只要业务查询只用 WHERE email = ?，第一个索引就毫无存在必要——pt-duplicate-key-checker 能自动发现这种隐性冗余。
立即学习“PHP免费学习笔记（深入）”；
- 别依赖「索引名含 _uniq 或 _pk」来判断是否唯一——名字不等于约束类型
-
SHOW CREATE TABLE table_name里看到的UNIQUE KEY和普通KEY都要一并纳入分析范围
哪些索引会被误判为「重复」但其实不该删
工具报告的「重复」只是基于字段前缀匹配，不考虑实际查询模式。有些索引看似冗余，但删了会明显拖慢特定查询。
- 复合索引
(a, b, c)和(a, b)：后者确实被覆盖，但如果高频查询只查a, b且返回大量行，MySQL 可能更倾向用短索引减少 I/O - 前缀索引如
KEY idx_title (title(100))和完整索引KEY idx_title_full (title)：工具可能忽略长度差异，误报重复 - 全文索引
FULLTEXT不参与重复检测逻辑，但名字撞了也会出现在结果里，需人工过滤
删之前必须确认的三件事
哪怕 pt-duplicate-key-checker 明确说某个索引冗余，也不能直接 DROP。先验证这三点：
- 查
information_schema.STATISTICS确认该索引最近 7 天是否被EXPLAIN或慢查询日志引用过 - 在测试环境执行
ALTER TABLE table_name DROP INDEX idx_name，再跑一遍核心业务 SQL，对比执行计划是否变化 - 检查是否有应用代码显式用到了这个索引名（比如
FORCE INDEX(idx_name)）
真正危险的不是重复索引本身，而是删掉后才发现某条关键报表 SQL 从 0.2s 慢到 8s——这种问题往往在凌晨发布后才暴露。
