搞数据分析的同学，谁没被“屎山”SQL代码折磨过？
在BI里，有一段470行的代码，确实慢，要跑 1000 多秒，将近17分钟！
每次查询量大一点业务都会来投诉
最近实在受不了了，就想用AI来优化一下，顺便看看现在这些当红炸子鸡们写SQL的能力到底怎么样。
所以如果你平时工作也有写SQL的需求，那么这篇文章可以帮你省下大把选AI工具的时间。
甚至可以直接拉到文末看结论。
统一给的提示词是一样的：
这是我的sql server语句，整体跑下来需要1039秒，太慢了，需要你帮我对它进行优化，提高查询速度，尽可能在100秒内完成。给我对当前查询问题的判断、优化的逻辑，以及最终改后的完整sql server代码即可：```源代码```Claude 4 ❌：速度快，但数据错了
拿到语句，跑了一下吓到了，确实是快，给我优化到不用1秒了，但从行数看得出来，数据错了。。
数据分析中，数据错就是原罪是不可原谅的，所以直接 pass
Gemini ❌：效果同 Claude4
Gemini 也翻车了，结果也是错的。
DeepSeek ❌：国产还是不行
国产之光DeepSeek，这次有点拉胯，直接就挂了，报错说我的查询有问题。得，连门都没进来。
Grok3✅：不错，终于有个靠谱的了
轮到马斯克的Grok 3。这次总算看到点希望了！
它给出的优化代码，跑下来只要32.5秒，而且最重要的是，返回行数是945行！跟原始数据一模一样！
从1039秒优化到32.5秒，同时保证了数据的正确性，这个效果已经很不错了，对于日常工作来说完全够用。
ChatGPT o3 ✅：卧槽，王者诞生！
卧槽，直接给干到7秒了
但不对诶，怎么是947行？
经验告诉我，差距这么小属于是误差，应该是哪里没清洗好。
于是我继续问GPT差距的原因，它给了几个语句，让我去查，优先是这里：
果然，我手动把原先的表结果和GPT的结果匹配后，得出的结论，跟它给的这个判断是一样的——原表有重复值。
也就是说，GPT不仅优化了我的代码，还顺手把我原始数据里的“坑”给找了出来。
它比我自己，更懂我写的“屎山”！这多出来的2行，不是它算错了，而是它更“正确”地处理了我的脏数据。
结论总结
模型特征差异：为什么 o3 表现这么好？
- 推理深度优先
o3 属“推理系列”，回答前会花更多计算在拆解步骤、判断风险；官方就把它定位在复杂、多步骤、答案不直接可见的问题上，并强调比前代在真实复杂任务上重大错误更少。
- 自查 + 工具链意识
o3 支持在 ChatGPT 里调用代码、文件、等工具，并被设计成可“自我核对 / 自查”式解题。这类模型更容易输出验证 SQL（查行数、查重复键）而不是只给一版改写。
我这案例中“差 2 行→让你检查重复”的互动就是典型自查路径。
- 编程任务基准强
o3 在 SWE-bench 等真实软件任务上创 SOTA；这说明它在读长代码、保持语义一致、逐步修改方面有训练优势，迁移到复杂 SQL 时表现更稳。
- 可调思考强度，面向可靠场景
o3 / o3-pro 提供更高 “思考时间”档位（reasoning effort） ，官方推荐在需要高可靠输出时使用；SQL 优化这类“性能+正确性”双高风险任务特别受益。
那 Claude / Gemini 为啥不行？（结合你测评）
Claude
Claude 3.5/后续家族强调智能 + 速度（较 Opus 提升 2x），并且在“提供工具时可独立写/改/跑代码”。在缺少你库结构、验证要求时，它倾向快速重写、 aggressively 精简；结果是性能上去了，逻辑被改，行数飘。
也就是说，给 Claude 时要明确“结果必须与原 SQL 一致”“先给验证脚本”，否则它可能优先交付速度。
Gemini
Google 的 Gemini 在线路里重点做“快速帮你写 SQL / 解释 SQL / 自动补全”；官方文档也提醒要在运行前验证生成的语句。面向“让更多人写得出 SQL”，而不是保证复杂多表、脏数据场景下 100% 口径一致。
怎么喂模型，才能又好又快？
其实我提示词是很简单的，但如果可以把这些和 SQL 一起贴给模型，翻车率下降：
原慢 SQL + 当前耗时
目标：性能阈值 & 结果必须一致
表结构（主键/索引）
已知脏数据（重复、NULL）
是否允许建索引 / 改逻辑
参考提示词：
提示词很长，并不是所有场景都需要，可以酌情去补。例如我今天这个查询优化的，直接让 AI 去优化，如果效果不行，再考虑补充对索引等方式的解释。
亦或是无法用 GPTo3 的，也就是大模型能力差点的，就只能通过补充更完整的提示词去优化结果。
# SQL Server 性能调优请求（保持结果一致）我有一段在 **SQL Server** 上运行的查询，当前完整 SQL 已贴在下方代码块中。 实际耗时约 **1039 秒**（取最近平均值 / 或填最新一次测量值）。 目标：**在不改变结果集（行数、金额、度量指标全部一致）的前提下，将执行时间压到 ≤100 秒**；如无法达成，请给出分档优化方案（≤300s、≤100s、≤30s）并说明所需额外条件。---## 已知信息（请用你需要的结构化方式复述并补充问题排查 SQL）- **数据库版本**：`<SQL Server 2019?>`（若未知请询问我）。- **数据日期范围**：`<YYYY-MM-DD ~ YYYY-MM-DD>`（与你 SQL 中筛选一致）。- **关键业务口径**：哪些字段/度量必须保持一致？（如：总行数、SUM(Amount)、SUM(qty)、SUM(retail_price)）。- **是否允许改写业务逻辑？** 默认 *不允许*；只可在不改变结果的情况下重排、裁剪数据扫描、预聚合等。若需改逻辑请先列出风险点让我确认。- **是否允许创建 / 建议索引？**（默认：可建议，不自动创建）。- **是否允许使用临时表 (#temp) 或物化中间结果？**（默认：**不允许**；若你认为必要，请解释收益与代价）。- **数据质量提示**：可能存在重复主键 / 多对多 / NULL / 数据倾斜；若需验证请生成检查 SQL。- **并行 / 内存 / 提示 (HINT)** 约束：若需使用 OPTION(RECOMPILE)、MAXDOP 等，请说明原因。---## 你需要输出的内容请按以下顺序，逐段输出（每段用清晰标题）：1. **快速复核**：复述我提供的业务口径、限制条件、性能目标；指出仍缺失的信息并向我提问。2. **瓶颈诊断**：基于查询结构（CTE、子查询、JOIN、CONVERT 导致索引失效等）推测主要耗时来源；给出我可执行的 `SET STATISTICS IO,TIME ON` / `EXPLAIN` / `ACTUAL EXECUTION PLAN` 指令清单。3. **数据正确性守护清单**：列出必须验证的指标（行数 / 金额 / 去重逻辑），并生成“原SQL vs 优化SQL”对比验证脚本。4. **分步优化建议（从低风险到高风险）**： - 重排过滤顺序 / 先裁剪再聚合 - 消除非 SARGable 谓词（如对日期列的 CONVERT） - 预聚合/派生表降基数 - 必要时的索引/统计信息建议 - 可选：物化或分阶段执行（若允许）5. **提供至少一个“安全优化版 SQL”**：保证结果一致，可直接替换测试；在代码内用注释标记关键改动。6. **（可选）激进优化版**：若放宽限制（如允许临时表或索引）能进一步降到 <X 秒，请给示例。7. **验证脚本**：自动生成 - 原SQL结果快照（行数、聚合指标） - 优化SQL结果 - 差异对比（行差、金额差、NULL 差） - 执行耗时采样（可用 temp table 存放测试指标；若不允许请改为表变量或内存统计）8. **后续排查指引**：如果实际跑时仍超时，告诉我接下来要收集哪些执行计划信息发你继续调优。---## 输出格式要求- 回答语言：**中文**（保留必要英文关键字）。 - 每段前加序号标题，便于复制。 - 所有 SQL 请包在 markdown ```sql 代码块内。 - 对于需要我补充的信息，用 `<!-- TODO: 填写 -->` 注释标识。 - 不要擅自更改业务逻辑；凡可能影响结果，请先提醒并等待我确认。 ---### 原始慢 SQL（请基于此分析）```sql-- 原始 SQL BEGIN<在此粘贴你的原始 SQL；保持完整，包括 CTE / 注释 / WHERE 条件>-- 原始 SQL END同样适合用 o3 的“强推理 + 高正确性”场景
下面这些工作都信息多、步骤长、结果必须对，用 ChatGPT o3 帮你拆步骤、生成检查脚本、做差异核对，能省很多坑：
大型代码库重构 / 接口迁移 ：跨多语言项目，要保持旧功能不坏，o3 可生成改动计划 + 回归测试清单。
财务 / 运营系统对账 ：订单、付款、发票数据来自不同系统；o3 帮你定义对齐字段、差异报表、预警规则。
实验 / A/B 分析流程复核 ：样本过滤、曝光口径、指标计算要一致；o3 可产出验证查询、统计对照步骤。（不限定用哪种分析工具）
多语言内容本地化一致性审校 ：术语、变量占位符、隐私条款不能错；o3 可批量对照源文 vs 翻译文。
合同 / 政策文档批量条款提取 ：找关键条款、标风险、比较版本差异；o3 生成结构化清单。
营销自动化流程调试 ：触发条件、频控、名单交集复杂；o3 帮你画流程、生成测试用例、模拟触发数据。
机器学习数据清洗 & 标签一致性检查 ：类别映射、缺失、分布漂移；o3 可输出检查脚本与数据质量报告。
自动化报表发布前的数据闸口 ：多源汇总，字段映射、缺失、阈值预警；o3 帮你生成预检任务。
用法小抄：把「输入数据来源、必须保持一致的指标、允许/不允许的改动、要输出什么检查脚本」一次性说清，o3 的表现通常更稳更快。
本文由稀土掘金作者【饼干哥哥】，微信公众号：【饼干哥哥AGI】，原创/授权 发布于稀土掘金，未经许可，禁止转载。
