文章目录 / 点击展开
AI 可以帮助发现 SQL 中的可疑连接、重复计算和缺少过滤，但它看不到真实数据分布、统计信息和数据库负载。任何索引或改写建议都必须通过执行计划和真实环境数据验证。
准备最小数据库上下文
至少提供数据库类型与版本、表结构、索引、字段含义、数据量级、关键字段基数、目标结果和当前耗时。不要上传真实用户数据、连接串或生产凭据。
数据库：PostgreSQL 16
目标：统计最近 30 天各渠道已支付订单金额
数据量：orders 8000 万行，users 500 万行
已知索引：orders(created_at)、orders(user_id)
约束：结果口径不能改变，允许新增索引但需评估写入成本第一步：先审查业务正确性
要求 AI 解释每个过滤、连接、聚合和去重的业务含义。重点检查 LEFT JOIN 是否被 WHERE 条件变成内连接、金额是否重复累计、时区是否一致、空值如何处理，以及状态字段是否覆盖完整。
先不要优化。请逐段解释 SQL 的结果口径，并列出可能导致漏数、重复、空值错误和时间边界错误的位置。每个问题给出最小样例数据。只有结果正确后才讨论性能。错误 SQL 即使更快，也没有价值。
第二步：识别潜在性能成本
让 AI 标记全表扫描、大量排序、重复子查询、函数包裹索引列、低选择性过滤和不必要的宽字段读取。要求区分“从 SQL 能确认”和“需要执行计划证明”。
对复杂查询画出表之间的连接顺序和预计行数变化。估算不能当事实，但能帮助选择需要重点观察的执行节点。
第三步：读取 EXPLAIN
在安全环境中获取 EXPLAIN 或 EXPLAIN ANALYZE。生产库执行 ANALYZE 前要确认查询成本和权限，避免对大表造成额外压力。
把计划中的实际行数、估算行数、扫描方式、循环次数、排序、临时文件和总耗时交给 AI，要求它引用具体节点解释瓶颈。
根据执行计划找出前三个主要成本。
比较估算行数与实际行数，说明统计信息或数据倾斜是否可能影响规划。
每条建议写明验证指标，不要只说“加索引”。第四步：评估索引建议
索引需要同时考虑过滤顺序、排序、覆盖列、写入成本和存储空间。低基数字段单独建索引不一定有效；组合索引的列顺序取决于查询模式，不是固定规则。
检查是否已有等价或前缀重叠索引。新增索引前记录目标查询、预期收益、写入影响和删除条件。
第五步：小步改写并对比
一次只修改一种因素，例如提前过滤、消除重复子查询或调整连接方式。使用相同参数和相近缓存状态比较耗时、读取行数、CPU、内存和结果一致性。
不要只测试一个“好看”的参数。至少覆盖常见值、极端值、空结果和数据倾斜场景。
审查检查清单
- 结果口径和时间边界是否先确认。
- 是否提供表结构、索引、数据量与字段基数。
- AI 的判断是否由执行计划或测试证明。
- 索引是否评估写入、存储和重叠成本。
- 改写前后结果是否逐行或聚合校验一致。
- 是否覆盖不同参数和数据倾斜场景。
- 上线后是否监控慢查询、锁等待和资源变化。
常见问题
AI 能只看 SQL 就给出正确索引吗
不能保证。索引效果依赖数据分布、现有索引、查询参数和数据库版本，必须结合执行计划验证。
EXPLAIN ANALYZE 可以直接在生产运行吗
它会真实执行查询。对大表、写操作或高负载环境应先评估风险，必要时使用只读副本或测试环境。
为什么优化后单次更快，整体却变慢
新索引可能增加写入和缓存压力，查询也可能在不同参数下选择更差计划。需要观察系统级指标而非单次耗时。
接口故障中的慢查询定位可结合 AI 接口日志分析，改写后应使用 AI 单元测试与边界用例 固化关键口径。