由 dawei 漏洞修复后，索引状态可能已偏离预期。安全补丁常涉及数据库权限调整、字段类型变更或逻辑过滤规则更新，这些操作虽修复了风险，却可能使原有索引失效、覆盖不全或匹配失效。例如，新增的WHERE条件若未被现有索引支持，查询将被迫回退至全表扫描，性能骤降。
重建索引不是简单执行DROP+CREATE命令，而是需结合修复后的业务逻辑重新评估索引设计。重点检查WHERE子句中高频过滤字段、JOIN关联键、ORDER BY排序字段及WHERE+ORDER BY组合场景。若漏洞修复引入了新校验字段（如status_valid、tenant_id），应将其纳入复合索引前导列，确保覆盖主搜索路径。
重建过程应避免业务中断。优先采用在线重建方式（如MySQL 8.0+的ALTER TABLE … ALGORITHM=INPLACE，PostgreSQL的CREATE INDEX CONCURRENTLY），在不影响读写的同时生成新索引。完成后，通过EXPLAIN分析典型查询执行计划，确认是否命中新建索引、扫描行数是否显著下降，并对比修复前后的平均响应时间变化。
建议图AI生成，仅供参考
需同步清理冗余索引。漏洞修复可能使旧索引失去存在价值——例如，原基于已被移除字段的索引、或被更优复合索引完全覆盖的单列索引。保留它们不仅浪费存储与写入开销，还拖慢INSERT/UPDATE速度。建议借助系统视图（如pg_stat_all_indexes、information_schema.STATISTICS）识别长期未被使用的索引。
最后一步是建立索引健康监控。将索引命中率、平均查询耗时、索引大小增长趋势纳入可观测性指标，设定阈值告警。尤其当后续上线新功能或修改查询逻辑时，自动触发索引适用性检查，形成“变更—评估—重建—验证”的闭环。让索引成为持续优化的资产，而非一次性的配置项。