智能索引生命周期：推荐建索引，也要知道什么时候删

智能索引生命周期：推荐建索引，也要知道什么时候删

一、索引推荐只解决一半问题

智能索引推荐工具通常关注慢查询，识别 WHERE、JOIN、ORDER BY 字段，然后建议新建索引。这个方向有用，但只解决了一半问题。索引一旦建上，就会增加写入成本、占用空间，并影响优化器选择。

索引治理不仅要会建，还要会观察、降级和删除。否则智能推荐会把数据库变成索引标本馆，看起来每个慢查询都被照顾了，整体写入和维护成本却越来越高。

二、索引要有生命周期

flowchart TD A[候选索引] --> B[影子验证] B --> C[灰度上线] C --> D[使用率观察] D --> E{是否有效} E -- 是 --> F[长期保留] E -- 否 --> G[下线删除]

候选索引先通过执行计划和回放查询验证。上线后观察命中率、查询收益、写入成本和空间增长。长期无命中的索引，应进入删除候选。

删除索引也要谨慎。某些低频查询虽然少，但业务重要。删除前要分析历史窗口，确认没有关键任务依赖。最好先标记 unused，观察一段时间，再真正删除。

三、指标要同时看读写

index_stats: name: idx_user_status_created read_benefit_ms: 420 write_overhead: medium size_gb: 18 last_used_at: "2026-07-03"

索引收益不能只看单次查询变快。要看查询频率、节省时间、影响行数、写入放大和磁盘占用。读收益小、写成本高的索引，很可能不值得保留。

EXPLAIN SELECT * FROM orders WHERE user_id = ? AND status = ?;

执行计划只是开始。上线后还要看真实运行统计，因为优化器可能在不同参数、不同数据分布下选择不同索引。

四、AI 推荐要输出理由和风险

AI 可以给候选索引，但必须说明覆盖哪些查询、预估收益、潜在写入成本和可替代方案。只给一句“建议建立联合索引”不够。

还要识别重复索引和前缀冗余。比如(a,b)和(a,b,c)是否都需要，要结合查询模式判断。智能推荐如果不懂现有索引结构，很容易制造重复。

索引上线还要看构建方式。大表直接建索引可能带来锁、IO 抖动和复制延迟。在线 DDL、低峰执行、分批观察和副本先行验证，都应进入流程。智能推荐不能只输出 DDL，还要输出执行窗口和回滚策略。

删除索引前，可以先做影子评估。把候选删除索引在测试环境或只读副本上隐藏，回放历史 SQL，看计划是否退化。直接在线删除，发现问题再重建，成本会很高。

复合索引字段顺序也需要解释。等值条件、范围条件、排序字段和覆盖字段的优先级不同。AI 推荐如果只列字段，不说明顺序依据，评审价值有限。

最后，索引治理要定期跑，不是慢查询出现才做。数据分布和查询模式会变，昨天有用的索引，今天可能只是写放大来源。

索引推荐还要和缓存层区分。有些慢查询在线上很少打到数据库，因为上层缓存命中率高。为这种查询建立重索引，收益可能被高估。推荐系统应结合真实数据库 QPS，而不是只看代码里的 SQL。

索引删除同样要考虑备份和恢复。删除前记录 DDL、索引定义、历史使用情况和删除原因。发现退化时，能快速重建，并知道为什么当初删除。索引治理需要可逆性。

索引治理看板应展示新增、删除和待观察索引。

五、总结

智能索引治理要覆盖候选、验证、灰度、观察、保留和删除整个生命周期。指标必须同时看读收益、写成本和空间占用。

会建索引只是开始。知道什么时候不建、什么时候删除，才是真正的索引治理。