智能索引生命周期推荐建索引也要知道什么时候删一、索引推荐只解决一半问题智能索引推荐工具通常关注慢查询识别 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、索引定义、历史使用情况和删除原因。发现退化时能快速重建并知道为什么当初删除。索引治理需要可逆性。索引治理看板应展示新增、删除和待观察索引。五、总结智能索引治理要覆盖候选、验证、灰度、观察、保留和删除整个生命周期。指标必须同时看读收益、写成本和空间占用。会建索引只是开始。知道什么时候不建、什么时候删除才是真正的索引治理。