数据库越来越慢，别急着让DBA背锅——我用AI把索引评审变成了一条流水线

一个管理者视角的困境

作为小团队的技术负责人，我经历过太多次这样的场景：业务方反馈“系统变卡了”，工程师排查半天，最后定位到是某几个慢查询拖垮了数据库。解决方案大家都懂——加索引。但真正的问题不在“加索引”这三个字，而在它背后的一整套流程：

慢查询日志动辄几百上千条，谁来筛？筛出来的SQL谁来分析该建什么索引？建索引会不会锁表、影响写入？上线后效果谁来验证？出了性能回退谁来兜底？

在一个没有专职DBA的团队里，这些问题的答案往往是“谁有空谁上”。于是索引优化变成了一个高风险、低优先级、没人愿意接的活——直到某天数据库CPU飙到90%,才被迫全员救火。

更让我担心的是风险控制：让初级工程师直接在线上库执行CREATE INDEX,一旦索引建错、建多，不仅没解决问题，还会拖慢写入、浪费存储。索引治理本质上是一个需要“评审”的动作，但小团队往往既没有人力也没有流程去做评审。

这是我把AI引入这个环节的初衷：不是替代人做决定，而是把“分析、建议、初审”这些重复劳动交给AI,让人只做最后的把关。

AI能在这个流程里做什么

先说清楚边界。AI不做的事：不直接连生产库、不执行任何DDL、不做最终决策。AI做的事：

1. 日志清洗与聚合：把杂乱的慢查询日志去重、归类，识别出Top N高频高耗SQL。
2. SQL分析：解析WHERE、JOIN、ORDER BY条件，判断现有索引是否命中。
3. 索引建议：给出建议的复合索引列顺序，并解释理由。
4. 风险评估初判：标记哪些表写入频繁、建议索引数量是否超标、是否可以用在线加索引的方式。
5. 产出评审文档：自动生成一份团队成员都能看懂的变更说明，供上线评审用。

整个流程变成：导出日志 → AI分析 → 人工评审 → 低峰期执行 → AI辅助验证效果。人的位置被清晰地放在了风险最高的两个节点上。

实际操作流程

我们团队的具体做法分五步：

第一步，脱敏导出。 从数据库导出慢查询日志(MySQL的话是slow.log,或通过performance_schema查询)，先做脱敏处理——把具体的参数值替换成占位符，去掉包含用户信息的字段。这一步必须人来做，是数据安全的第一道闸门。

第二步，喂给AI分析。 把脱敏后的日志和表结构(SHOW CREATE TABLE的输出)一起给AI。注意：给表结构非常关键，否则AI只能猜索引，无法判断是否已有可复用的索引。

第三步，拿到结构化建议。 我要求AI以固定格式输出：每条建议包含原SQL、问题诊断、建议索引DDL、预期收益、风险提示。格式统一的好处是，团队成员评审时不需要来回适应不同的表达方式。

第四步，人工评审会。 15分钟的站会过一遍AI的建议清单，工程师按“采纳/搁置/拒绝”三档打标。经验表明，AI建议的采纳率大概在七成左右——被拒的那三成往往是AI不知道业务背景(比如某张表即将弃用)，这正是人工把关的价值。

第五步，灰度执行与验证。 低峰期逐条执行，执行前后各采集一次查询耗时对比，再让AI帮忙生成验证报告。

可复制的提示词模板

这是我们团队沉淀的模板，配合任意支持长上下文的大模型使用即可：

你是一位数据库性能优化顾问。请根据我提供的慢查询日志和表结构,给出索引优化建议。

【输入材料】
1. 慢查询日志(已脱敏):
<在此粘贴慢查询日志>

2. 相关表结构(SHOW CREATE TABLE 输出):
<在此粘贴建表语句>

3. 数据库类型与版本:
<如 MySQL 8.0>

【输出要求】
请按以下格式逐条输出,不要省略任何一栏:

## 建议 N
- 原始SQL:(粘贴日志中的代表性SQL)
- 出现频次与平均耗时:(从日志统计)
- 问题诊断:(说明为何现有索引未命中,引用WHERE/JOIN/ORDER BY条件)
- 建议索引DDL:(给出完整CREATE INDEX语句,注明复合索引的列顺序及理由)
- 预期收益:(预估该查询的扫描行数变化)
- 风险提示:(写入放大、索引冗余、是否建议改用 ONLINE 方式、是否建议合并到已有索引)
- 验证方法:(执行后应观察什么指标)

【约束】
1. 不确定的业务背景请明确标注"需人工确认",不要臆测
2. 单表建议索引总数超过5个时,请给出取舍建议
3. 如发现SQL本身可改写(如SELECT *、隐式类型转换),请单独列出
4. 最后输出一份汇总表格,按"预期收益/风险等级"排序,便于评审

前后对比：从“救火”到“例行公事”

改造前后的变化，用我们团队的真实体感来描述：

成本方面：这个流程只消耗模型的token费用，相比工程师投入的人力时间，几乎是零头量级。具体价格以官网价格页为准，不同模型差异较大，建议先用中等成本的模型跑通流程，再评估是否需要更强的模型。

几点给管理者的提醒

第一，脱敏环节不能交给AI自觉。日志里有没有敏感数据，必须由人确认后再提交。第二，AI的建议要当作“评审材料”而非“执行脚本”，最后那道人工确认不可省略。第三，把提示词模板固化到团队文档里，避免每个人各写各的，产出格式漂移。

索引优化只是开始。同样的“AI初审+人工终审”模式，完全可以复制到慢SQL改写、容量预警、巡检报告等场景。对于想动手试的团队，可以注册一个API账号直接开始：https://api.thistoken.ai/register

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。