sql索引冗余指多个索引在相同列上存在前缀重叠，导致部分索引无法被优化器选用、浪费存储并拖慢写入；识别需结合元数据比对（如information_schema或pg_index）、工具扫描（如pt-duplicate-key-checker）及运行时使用率（idx_scan）和执行计划验证，删除前须评估约束语义、锁影响并做好回滚准备。
SQL索引冗余主要指多个索引在相同列上具有相同或前缀重叠的排序和过滤能力，导致部分索引实际无法被优化器选用，白白占用存储、拖慢写入性能。识别重复索引是数据库调优的关键一步。
看索引列顺序与覆盖范围是否实质重叠
重复索引的核心判断依据是：一个索引的列前缀（按定义顺序）完全包含另一个索引的全部列，且两者均为B-Tree类型、方向一致（如都是ASC）、无表达式或函数封装。
- 例如：
INDEX idx_a_b (a, b)和INDEX idx_a (a)—— 后者被前者完全覆盖，WHERE a = ?查询可走idx_a_b，idx_a即为冗余 - 但
INDEX idx_b_a (b, a)与idx_a_b不构成重复，因最左前缀不同，适用场景不同 -
INDEX idx_a_desc (a DESC)与idx_a (a ASC)在mysql 8.0+可能共存有用（如混合排序需求），但多数情况下ASC/DESC混用会削弱复用性，需结合实际执行计划评估
用系统表或专用工具扫描候选重复项
不同数据库提供不同元数据视图，可编写SQL快速比对：
- MySQL：查询
information_schema.STATISTICS，按table_schema、table_name、index_name分组，提取各索引的seq_in_index列名序列，再两两比对前缀关系 - postgresql：联查
pg_class、pg_index、pg_attribute，通过indkey获取列序号，还原出索引列顺序后做子集判断 - 推荐工具：
pt-duplicate-key-checker（Percona Toolkit）可直接输出疑似重复/冗余索引，并提示删除建议；pg中可用pg_qualstats或pg_stat_all_indexes辅助验证实际使用率
结合实际查询负载验证“是否真冗余”
元数据层面的重复不等于运行时冗余——有些索引虽被覆盖，却因统计信息偏差、绑定变量窥探、或特定ORDER BY/GROUP BY需求而被选中。
- 检查
performance_schema.table_io_waits_summary_by_index_usage（MySQL 8.0+）或pg_stat_all_indexes（PG）中的idx_scan，长期为0的索引优先标记 - 对疑似冗余索引，用
EXPLAIN FORMAT=json对典型查询强制指定索引（如USE INDEX(idx_a)），对比执行计划中是否真的跳过、是否引入filesort或临时表 - 注意唯一索引（UNIQUE）和主键（PRIMARY）不可简单删除——即使列被覆盖，其约束语义不可替代
删除前务必做变更控制与回滚准备
索引删除是DDL操作，在大表上可能阻塞DML，且不可回滚（除非提前备份执行计划或建影子索引）。
- 生产环境避免直接
DROP INDEX，建议先用ALTER TABLE ... DROP INDEX在低峰期执行，并监控锁等待与慢查询日志 - 删除后观察3–7天：QPS、平均响应时间、buffer pool命中率、以及是否有新慢查出现
- 保留删除记录与回滚语句（如重建索引的完整DDL），便于紧急恢复