直接回答：避免AI SQL出问题的顺序应是“正确性校验 → 执行计划 → 最小优化 → 再次对账”。不要让AI只凭SQL文本猜性能；把表结构、索引、数据规模和EXPLAIN结果一起给它，并要求所有优化都通过结果一致性检查。[1]
第一原则：先证明结果正确，再谈快不快
AI写出的SQL即使语法正确，也可能因为连接条件、NULL语义、时间范围或聚合口径错误而返回“看起来合理”的错数据。先用小样本和已知答案核对行数、主键集合、合计值和边界日期，再进入性能优化。
用EXPLAIN看数据库实际准备怎么执行
PostgreSQL的EXPLAIN用于查看查询计划，EXPLAIN ANALYZE会实际执行语句并提供运行信息。对写操作或有副作用语句使用ANALYZE前必须特别谨慎。[1]
| 症状 | AI应检查 | 验证方式 |
|---|---|---|
| 全表扫描 | 过滤列、数据量、索引可用性 | EXPLAIN/ANALYZE |
| 连接很慢 | JOIN键、基数估计、连接顺序 | 执行计划+真实行数 |
| 结果重复 | 1:N连接、缺少唯一键 | 主键/业务键去重检查 |
| 合计错误 | NULL、过滤条件、聚合粒度 | 抽样手算+分组对账 |
| 分页漂移 | 无稳定ORDER BY | 固定排序键后重复执行 |
让AI优化时必须给什么
- 表结构、索引和约束；
- SQL原文；
- EXPLAIN (ANALYZE, BUFFERS)输出（可脱敏）；
- 大致数据量和选择性；
- 允许改SQL、索引还是表结构；
- 正确结果的验收规则。
结果校验要做“双轨”
对关键报表，保留旧查询或简单但可靠的基线查询，在同一快照上比较行数、关键ID集合、聚合和异常样本。性能变快但业务口径变化，属于失败而不是优化成功。
可复制提示词
目标：优化下面SQL，但不能改变业务结果。
输入：表结构、索引、SQL、EXPLAIN ANALYZE。
请先指出可能的正确性风险，再解释计划中的高成本节点。
每个修改都给：原因、预期影响、需要新增的索引、验证SQL。
最后给一组“旧SQL vs 新SQL”的结果一致性检查。参考来源
- PostgreSQL Docs：Using EXPLAIN（核验于 2026-08-08）
- PostgreSQL Docs：MVCC（核验于 2026-08-08）
更新记录
- 2026-08-08：核验官方资料并完成全文结构化撰写。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
百度热点