用 AI 解决数据库性能问题的方法论

1. 先定目标：不是让 AI 猜答案，而是让 AI 帮你收敛问题

很多人用 AI 的第一反应是：

• “帮我看看为什么慢”
• “是不是索引问题”
• “是不是死元组问题”

这类问法的问题是：过早进入猜答案模式。

更好的用法是把 AI 当成下面三种角色：

1. 问题拆解器 把一个模糊问题拆成若干个可验证的小问题。

2. 实验设计器 告诉你下一步该拿什么证据，跑什么 SQL，写什么脚本，如何对比两个环境。

3. 结论整理器 在你拿到一堆日志、执行计划、表统计后，帮你抽出真正重要的差异点。

一句话：

AI 最有价值的地方，不是直接给最终答案，而是帮助你建立“证据链”。

2. AI 介入这类问题的标准流程

面对一个性能问题，建议把和 AI 的协作分成 4 个阶段。

阶段 1：定义问题

这一阶段不要急着贴一大堆日志，先让 AI 帮你把问题定义清楚。

建议输入：

• SQL 是什么
• 在哪个环境慢，哪个环境快
• 大概慢多少
• 是端到端慢，还是数据库执行慢
• 是否是表、视图、存储过程

你可以这样问：

这条 SQL 在 A 环境 8 秒，在 B 环境 0.2 秒。
它查的是一个复杂视图。
请不要先猜原因，先帮我设计一个排查框架：
我应该先确认哪些事实？
哪些结论可以从哪些证据推出？

这一步的目标不是得出原因，而是得到一份：

• 先查什么
• 后查什么
• 哪些因素优先排除

的路线图。

阶段 2：采证

这一阶段 AI 的价值最大。

因为很多人知道“要看执行计划”，但不知道：

• 除了执行计划还要看什么
• 两个环境怎样对比才有意义
• 如何避免一次查太多信息把自己淹没

此时适合让 AI 帮你生成：

1. 最小验证脚本 比如 Java demo、shell 命令、SQL 集合。

2. 对比采集脚本 比如同一份程序切换不同数据源，输出统一格式结果。

3. 分层计时方案 比如连接耗时、执行耗时、首行耗时、遍历耗时。

好的问法：

请帮我设计一个最小程序，输出：
1. connect time
2. query first-row time
3. fetch time
4. explain analyze
5. 关键基表的行数、大小、死元组比例
要求输出格式统一，方便我对比两个环境。

这时 AI 的作用是：把“想法”变成“可重复执行的采集动作”。

阶段 3：归因

这一步是最容易跑偏的。

因为你一旦看到某个指标异常，就容易立刻下结论。

例如：

• 死元组高，就说是死元组问题
• 某表大，就说是数据量问题
• 有 Seq Scan，就说是索引问题

而 AI 在这里最适合做的是：

强迫你做“差异归因”而不是“单点归因”。

也就是：

• 不看一个环境，要看两个环境的差异
• 不看一个指标，要看哪个指标和性能差异最相关
• 不要问“这个是不是原因”，而要问“这个能否解释环境间差异”

好的问法：

下面是快环境和慢环境的对比结果。
请不要罗列所有差异，只挑出最能解释“为什么一个快一个慢”的前 3 个差异。
并说明：
1. 这个差异是什么
2. 为什么它能解释性能差异
3. 为什么其他差异更像次要因素

这个问法很重要。

因为真正的分析不是“发现异常”，而是“判断哪个异常最有解释力”。

阶段 4：沉淀

大多数排查最后停在“问题解决了”。

真正高价值的做法是让 AI 帮你沉淀成可复用资产：

• 一份结论文档
• 一份排查 checklist
• 一套可复用 demo
• 一套以后可以复制粘贴的 prompt 模板

这一阶段可以让 AI 帮你写：

请把这次排查过程抽象成一份方法论：
重点不是这条 SQL 本身，而是以后遇到“同一 SQL 在不同环境性能不一致”时，
应该如何借助 AI 分阶段定位问题。

3. 用 AI 时最重要的三个思维切换

思维一：从“要答案”切换到“要框架”

低效问法：

为什么慢？

高效问法：

先别猜原因。
请按“连接/执行/传输/客户端处理”四层帮我拆解，
并告诉我每层各需要什么证据。

区别在于：

• 前者会让 AI 直接猜
• 后者会让 AI 帮你搭分析框架

思维二：从“看异常”切换到“看差异”

性能问题里，异常很多，但不是每个异常都重要。

例如：

• 慢环境死元组多一点
• 慢环境某表大一点
• 慢环境某索引名字不一样

这些都可能是噪声。

真正关键的是：

什么差异最能解释“为什么只有这个环境慢”。

所以要让 AI 做“差异解释”，而不是“异常罗列”。

思维三：从“凭经验判断”切换到“设计验证”

高手和普通人的最大差别，不是知道更多名词， 而是会把猜想立刻转成验证动作。

比如怀疑“数据量问题”，不要停在怀疑， 而是马上让 AI 帮你设计：

• 哪几张表应该 count
• 看精确 count 还是 reltuples
• 怎么对比两个环境
• 如何避免权限不足或 schema 写错

AI 的价值就在这里：

把模糊的怀疑，立刻转成可执行的验证。

4. 一个通用的 AI 排查模板

以后碰到类似问题，可以按下面这个模板跟 AI 对话。

第一步：定义问题

我有一个数据库性能问题：
1. SQL/接口：xxx
2. 慢环境：A，耗时 xxx
3. 快环境：B，耗时 xxx
4. 对象类型：表 / 视图 / 存储过程

请先不要猜原因。
先帮我建立一套排查框架：
从哪些层次拆？
每层要收集什么证据？

第二步：生成采证脚本

请基于上面的框架，帮我生成一个最小诊断程序/脚本：
要求统一输出：
- connect time
- explain analyze
- 关键表 count / size / dead tuple
- 环境信息
方便我复制到两个环境分别执行。

第三步：做差异分析

下面是两个环境的执行结果。
请只输出：
1. 最关键的 3 个差异
2. 每个差异为什么能解释性能差异
3. 哪些看起来异常但不是主因

第四步：沉淀复用

请把这次分析抽象成一份方法论文档：
重点不是这个 SQL，
而是以后如何用 AI 处理“同 SQL 不同环境性能差异”问题。

5. 这次案例里，AI 真正帮到的地方是什么

用这次问题举例，AI 的价值不是“知道 PostgreSQL 多厉害”，而是：

5.1 帮你从混乱信息里抓主线

原始现象里同时存在很多线索：

• 查询慢
• 是视图
• 不同环境速度不同
• 有可能是死元组
• 有可能是数据量
• 有可能是索引
• 有可能是打印慢

如果没有框架，很容易乱。

AI 帮你做的是：

1. 先拆成连接、执行、输出三段
2. 再确认主要慢在服务端
3. 再定位最慢的视图分支
4. 再对比两个环境的数据规模

这就是“从乱到序”。

5.2 帮你快速产出辅助程序

很多问题不是不会分析，而是懒得写采证代码。

AI 很适合：

• 快速写 demo
• 快速改 demo
• 快速加新统计项
• 快速切第二套数据源

它让“做验证”的成本下降很多。

5.3 帮你组织对外表达

技术上查明白是一回事， 能不能讲清楚又是另一回事。

AI 可以帮你生成两种表达：

1. 技术版 说给开发 / DBA 听。

2. 业务版 说给产品 / 用户 / 管理层听。

比如这次就可以用一句非常清楚的人话表达：

这就是“证据支持下的简洁表达”。

6. 使用 AI 时最容易踩的坑

坑 1：一次丢给 AI 太多未经整理的原始日志

坏处：

• AI 很容易被噪声带偏
• 结论会变成泛泛而谈

更好的方式：

• 先让 AI 告诉你“需要哪些关键证据”
• 再分批提供

坑 2：还没验证就让 AI 下结论

比如直接问：

• “是不是索引没建？”
• “是不是死元组太多？”

这类问法会让 AI 顺着你的暗示走， 最后你得到的是“看起来合理”的解释，不一定是真因。

坑 3：把 AI 当作权威，而不是搭子

AI 最适合：

• 提出假设
• 设计实验
• 组织材料

但最终判断仍然依赖：

• 真实执行结果
• 真实执行计划
• 真实环境差异

所以正确姿势是：

AI 提假设，人拿证据；AI 帮归纳，人做判断。

7. 一个最值得复用的核心原则

以后遇到任何类似问题，都记住一句话：

不是：

这个区别非常大。

前者会越来越稳， 后者会越来越玄学。

8. 最后给自己的复盘问题

每次用 AI 排完一个性能问题后，可以问自己 5 个问题：

1. 这次最关键的证据是什么？
2. 我一开始最先怀疑的点，最后证明是主因还是噪声？
3. 哪个验证动作最有价值？
4. 如果下次重来，我会先做哪 3 步？
5. 哪些内容可以沉淀成固定脚本、固定 prompt、固定 checklist？

只要持续复盘，AI 就不只是“帮你一次”， 而是逐渐成为你解决复杂问题的思维放大器。

9. 一句话总结

AI 解决这类问题的正确方式，不是替你判断，而是替你搭框架、出实验、做对比、收结论。

它最强的不是“数据库知识”，而是：

• 帮你把复杂问题拆小
• 帮你把怀疑变成验证
• 帮你把证据变成结论
• 帮你把一次经验变成可复用的方法