智能索引推荐：少建一个错索引，比多建三个索引更重要

索引推荐是 AI 数据库助手最常见的功能之一。看到慢查询，就建议建索引；看到过滤条件，就建议联合索引。问题是，索引不是免费的。它会增加写入成本、占用空间、影响优化器选择，还可能和已有索引重复。

智能索引推荐的目标不是“多推荐”，而是少建错索引。

一、索引推荐要看全局负载

flowchart TD
  A[Query Workload] --> D[Index Advisor]
  B[Write Workload] --> D
  C[Existing Indexes] --> D
  D --> E[Candidate Index]
  E --> F[Benefit Cost Review]

只看单条慢查询，很容易给出局部最优建议。一个索引让查询快了 30%，但让写入慢了 20%，未必值得。

二、候选索引要去重

推荐前先检查已有索引是否覆盖。

SHOW INDEX FROM orders;

对于联合索引，左前缀规则要考虑清楚。已有 (user_id, created_at) 时，再建 (user_id) 可能没有必要；但如果排序、覆盖列不同，也不能简单合并。

三、收益要用真实计划验证

AI 可以给候选，但必须通过 hypothetical index、影子库或测试环境验证执行计划。

EXPLAIN FORMAT=JSON
SELECT *
FROM orders
WHERE user_id = ? AND status = ?
ORDER BY created_at DESC
LIMIT 20;

看扫描行数、回表次数、排序方式和代价变化。只看“用了索引”是不够的，用错索引也会慢。

四、写入成本要量化

索引会影响 insert、update、delete。推荐报告里应包含空间估算和写入影响。

index_candidate:
  table: orders
  columns: [user_id, status, created_at]
  estimated_size_gb: 18
  affected_write_qps: 3200
  expected_query_gain: "p95 -42%"

如果表很大，建索引本身也要考虑 online DDL 风险、复制延迟和回滚方案。

索引推荐还要考虑生命周期。有些索引只为一次活动或一次迁移服务，长期保留会拖累写入。推荐报告可以给出过期时间和复查条件。

index_lifecycle:
  owner: "order-team"
  review_after: "2026-08-01"
  remove_if:
    - "query_digest_qps < 1 for 14 days"
    - "write_latency_regression > 5%"

数据库里最容易堆积的债，就是“当时很有用”的索引。没有复查机制，索引集合迟早变成化石层。

五、总结

智能索引推荐不能只看单条 SQL。它要结合全局查询负载、写入负载、已有索引、真实执行计划和建索引风险。

少建一个错索引，比多建三个看似有用的索引更重要。数据库优化不是收藏索引，是控制系统整体代价。

所以智能索引推荐的最终输出不应该是“建不建”，而是一份收益、成本、风险、验证和生命周期都清楚的变更建议。

如果这份建议不能说明影响哪些查询、拖慢哪些写入、占用多少空间、怎么回滚，那它还只是一个猜测，不是可以进入生产的索引方案。

生产数据库不缺建议，缺的是能负责的建议。

这也是索引治理的底线。