SQL数据库无索引回收机制，无效索引需人工识别清理：零使用率、被覆盖、低选择性前导列、冗余唯一约束等；应结合统计视图与执行计划验证，并确认无应用依赖、评估写入开销、先禁用后观察再删除。
SQL数据库中没有“索引回收机制”这一标准概念，索引不会像内存或事务日志那样被自动“回收”。所谓“无效索引”，通常指**未被查询使用、重复冗余、或因数据变更而实际失效的索引**。数据库本身不会主动删除它们，必须由DBA或开发人员识别并手动清理。
哪些索引算“无效”？关键识别维度
判断一个索引是否无效，不能只看定义，需结合运行时行为和业务逻辑：
-
零使用率：在较长时间（如7–30天）内，
sys.dm_db_index_usage_stats（SQL Server）或pg_stat_all_indexes（PostgreSQL）中user_seeks + user_scans + user_lookups = 0 -
被覆盖索引替代：存在一个更宽的索引（如
(a, b, c)），而另一个索引仅为(a, b)，后者通常不再必要 -
前导列选择性极低：例如在
gender（仅'男'/'女'）上建单列索引，且查询条件未配合高选择性过滤，优化器大概率忽略它 -
唯一约束已由主键/其他唯一索引保证：比如表有主键
id，又为id单独建了非聚集唯一索引，属冗余
如何安全识别无效索引（以SQL Server为例）
执行前确保已收集足够周期的使用统计（重启服务后统计清零）：
SELECT t.name AS table_name, i.name AS index_name, i.type_desc, i.is_unique, i.is_primary_key, s.user_seeks, s.user_scans, s.user_lookups, s.last_user_seek, s.last_user_scan FROM sys.dm_db_index_usage_stats s INNER JOIN sys.indexes i ON s.object_id = i.object_id AND s.index_id = i.index_id INNER JOIN sys.tables t ON i.object_id = t.object_id WHERE s.database_id = DB_ID() AND t.is_ms_shipped = 0 AND i.name IS NOT NULL AND (s.user_seeks + s.user_scans + s.user_lookups) = 0 ORDER BY s.last_user_seek ASC;
注意：结果仅反映统计周期内的使用情况，上线新功能或报表任务可能尚未触发，需结合执行计划验证。
PostgreSQL 和 MySQL 的对应方法
PostgreSQL：查 pg_stat_all_indexes，重点关注 idx_scan 为 0 且存在较久的索引；再用 EXPLAIN (ANALYZE, BUFFERS) 检查关键查询是否真用到了该索引。
MySQL（8.0+）：启用 performance_schema，查询 table_io_waits_summary_by_index_usage，筛选 COUNT_STAR = 0 的索引；同时检查 information_schema.STATISTICS 中重复的列组合。
清理前必须做的三件事
-
确认无应用依赖：搜索代码库、ORM配置、存储过程、视图、物化视图中是否显式引用该索引名（如 SQL Server 的
WITH (INDEX(...))） - 评估写入开销：即使未被读取，该索引仍在INSERT/UPDATE/DELETE时维护——删除后可降低写延迟与存储占用
-
先禁用再观察（SQL Server）：用
ALTER INDEX ... DISABLE临时停用，监控业务指标与慢查询日志，确认无异常后再DROP
