慢查询怎么破？掌握AI写SQL提示词让复杂查询与性能调优更轻松

很多人在数据库出现慢查询时，习惯直接把一段两百多行的 SQL 复制给大模型，附上一句“帮我优化一下”。

结果往往很尴尬：AI 回复了一堆看似头头是道的理论，改写出来的 SQL 要么执行报错，要么跑起来比原来还要慢。

大模型并不是数据库底层的基于成本的优化器（CBO）。它看不到真实的磁盘 I/O 分布，不知道单表的实际物理行数，更无法感应列基数（Cardinality）与数据倾斜程度。单纯给大模型一段纯文本 SQL，它只能在语法表层做同义替换。

要让 AI 真正成为调优帮手，核心不在于大模型多聪明，而在于你喂给它的上下文结构是否符合数据库执行引擎的工作原理。

一、模型选型与核心推理参数配置

不同大模型在处理复杂 SQL、长文本执行计划（Execution Plan）和复杂关联逻辑时的表现存在明显差异。

在实际生产场景中，针对主流大模型的实测对比如下：

调优推理参数设定

调优 SQL 属于高度确定性的工程任务，必须尽可能消除大模型的随机发散倾向。建议在调用 API 或配置客户端时，采用以下参数组合：

•Temperature（采样温度）：建议设为 0.0 至 0.2。过高的温度会导致大模型凭空编造数据库方言函数或虚构索引字段。

•Top-P（核采样）：建议设为 0.1 至 0.2，与低温度配合，强制模型只选取置信度最高的语法结构。

•System Prompt 角色约束：明确数据库版本（如 PostgreSQL 16、MySQL 8.0.35 等），因为不同小版本之间的优化器行为和索引特性（例如不可见索引、函数索引支持）差异很大。

二、五步结构化提示词框架设计

单薄的指令必然带来劣质的输出。想要让 AI 给出精准的优化方案，提示词必须覆盖执行引擎所需的五大核心要素：

1.引擎环境与版本：指明数据库类型与具体版本号。

2.表结构与索引现状（DDL）：包含字段类型、主键、现有普通索引及复合索引顺序。

3.数据规模与分布特征：给出主表与关联表的数据量级、热点过滤字段的基数（Cardinality）。

4.原始 SQL 与真实执行计划：提供当前耗时，以及 `EXPLAIN ANALYZE`（MySQL/PostgreSQL）的输出。

5.重构边界与硬性约束：说明是否允许新增索引、是否允许拆分事务、是否禁止使用特定语法（如临时表）。

这里是一套经过多次生产压测验证的通用调优提示词模板，可以直接存入你的提示词库：

### 角色与任务
你是一位资深数据库性能调优专家（DBA）。请根据我提供的数据库元数据、慢查询 SQL 以及真实执行计划，分析性能瓶颈，给出优化后的 SQL 及配套索引建议。

### 运行环境
- 数据库引擎及版本：[例如：MySQL 8.0.32 / InnoDB]
- 关键配置：[例如：innodb_buffer_pool_size=16G]

### 结构元数据 (DDL & 统计信息)

— 在此粘贴相关表的 CREATE TABLE 语句（包含现有索引）

- 数据量级：
  - [表A]：约 [5,000,000] 行，每日增量约 [20,000] 行
  - [表B]：约 [200,000] 行，字段 [status] 的取值仅有 3 种

### 性能瓶颈现状
- 当前平均耗时：[例如：4.8 秒]
- 期望目标耗时：[例如：300 毫秒以内]
- 原始 SQL：

— 在此粘贴原始慢查询 SQL

- 真实执行计划 (EXPLAIN / EXPLAIN ANALYZE)：

— 在此粘贴命令行或管理工具中导出的完整执行计划文本

### 分析与重写规则
1. 第一步：分析执行计划中的关键阻塞点（如全表扫描 Full Table Scan、临时表 Disk Temporary Table、文件排序 File Sort、驱动表选择不当）。
2. 第二步：分析现有索引是否失效，是否存在隐式类型转换、最左前缀截断或谓词计算导致无法走索引。
3. 第三步：在保证业务等价性的前提下重写 SQL。优先考虑覆盖索引规避回表、延迟关联、将子查询转换为 JOIN、或者优化分页逻辑。
4. 第四步：若必须补充索引，给出精确的组合索引字段顺序，并说明依据。

### 输出格式规范
请严格按照以下结构输出，杜绝虚话套话：
1. 【瓶颈根因诊断】：列出 2-3 个核心瓶颈点及证据（定位到执行计划的具体行）。
2. 【优化后 SQL】：给出完整且符合原逻辑的代码块。
3. 【配套索引方案】：给出可直接执行的 DDL 语句，并标明创建顺序。
4. 【预期收益与风险评估】：说明重写对查询成本（Cost）的预计降低幅度，以及可能引入的副作用（如写性能影响）。

三、真实复杂场景实测：多表关联与深分页优化

为了验证上述结构化提示词的实际效果，我们来看一个典型的电商中台慢查询案例。

1. 业务痛点

业务后台需要查询“近 30 天内已完成支付且订单金额大于 500 元的特定渠道用户订单列表”，并支持深度分页查看。

原始 SQL 如下：

SELECT 
    o.id, o.order_sn, o.user_id, o.total_amount, o.pay_time, 
    u.username, u.phone, 
    p.pay_channel, p.transaction_id
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
LEFT JOIN payments p ON o.order_sn = p.order_sn
WHERE o.status = 'PAID'
  AND o.created_at >= '2025-02-01 00:00:00'
  AND o.total_amount > 500.00
  AND p.pay_channel = 'WECHAT'
ORDER BY o.created_at DESC
LIMIT 100000, 20;

在测试环境中，`orders` 表数据量为 820 万行，`users` 表 120 万行，`payments` 表 850 万行。执行上述查询耗时 6.82 秒。

通过 `EXPLAIN ANALYZE` 发现：

1.`LIMIT 100000, 20` 导致数据库必须扫描并回表读取前 100020 行记录，随后丢弃前 10 万行，存在巨量无效 I/O。

2.`payments` 表虽然在 `order_sn` 上有索引，但在与主表连接过滤 `p.pay_channel = ‘WECHAT’` 时触发了大量回表校验。

3.优化器在选择驱动表时，对多表做连接计算消耗了大量的临时内存，随后触发了磁盘文件排序（File Sort）。

2. 将上下文输入大模型后的分析推演

借助上述提示词框架，将 DDL、数据量、执行计划一并输入 Claude 3.5 Sonnet，模型准确识别出深分页的大量无用回表，并给出了基于“延迟关联（Deferred Join）”与“覆盖索引裁剪”的重写方案。

大模型输出的重写后 SQL：

-- 优化后方案：先通过覆盖索引仅提取分页主键，再回表获取明细与关联字段
WITH target_orders AS (
    SELECT o.id
    FROM orders o
    JOIN payments p ON o.order_sn = p.order_sn
    WHERE o.status = 'PAID'
      AND o.created_at >= '2025-02-01 00:00:00'
      AND o.total_amount > 500.00
      AND p.pay_channel = 'WECHAT'
    ORDER BY o.created_at DESC
    LIMIT 100000, 20
)
SELECT 
    o.id, o.order_sn, o.user_id, o.total_amount, o.pay_time,
    u.username, u.phone,
    p.pay_channel, p.transaction_id
FROM target_orders t
JOIN orders o ON t.id = o.id
LEFT JOIN users u ON o.user_id = u.id
LEFT JOIN payments p ON o.order_sn = p.order_sn
ORDER BY o.created_at DESC;

配套给出的索引调整方案：

-- 为 orders 表补充针对过滤与排序的最优复合索引
CREATE INDEX idx_orders_status_created_amount ON orders (status, created_at DESC, total_amount, id, user_id, order_sn);

-- 为 payments 表补充覆盖连接与过滤的复合索引
CREATE INDEX idx_payments_ordersn_channel ON payments (order_sn, pay_channel);

3. 优化前后实测指标对比

在相同硬件环境（8C16G，NVMe SSD，MySQL 8.0）下重放查询，两者的实际监控指标对比如下：

四、日常写 SQL 与调优的 SOP 工作流

在日常工作中，不要把 AI 当成一步到位的魔法棒，而要建立标准化、闭环的工作流：

[生产慢日志 / APM 报警]
          ↓
[脱敏抓取：SQL 原句 + DDL + EXPLAIN ANALYZE 文本]
          ↓
[组装结构化 Prompt（严格设定 Temperature=0.1）]
          ↓
[大模型解析诊断 → 产出：改写 SQL + 索引规划]
          ↓
[测试环境实测验证：执行 EXPLAIN ANALYZE 对比 Cost]
          ↓
[代码 Review 与上线灰度监控]

注意看这个流程中的第四步与第五步。大模型生成的任何 SQL 或索引方案，必须经过测试环境验证成本（Query Cost）与扫描行数，严禁直接在生产环境执行。

五、必须警惕的三大避坑要点

在实际落地过程中，有几个极易踩坑的隐患，必须保持清醒认知：

1. 警惕“幻觉索引”与方言不兼容

大模型偶尔会凭空建议一些当前数据库不支持的语法特性。例如在 MySQL 5.7 环境中建议使用哈希索引（Hash Index）或部分索引（Partial Index），或者在不支持并行的低版本中添加并行查询 Hint。

防范手段：在提示词中必须写明精确的小版本号，并在收到索引建议后，第一时间在官方文档或测试库中验证该 DDL 是否合法。

2. 严守数据安全红线，杜绝明细泄露

向公网大模型发送调试信息时，严禁附带真实的业务明细数据。

•表名、字段名如果涉及核心敏感资产，可以使用通用别名（如 `t_order`、`col_1`）替代。

•执行计划中的统计数据是安全的，但如果使用了 `EXPLAIN ANALYZE` 打印了具体过滤条件的值，必须将用户的手机号、身份证、真实金额等替换为占位符。

3. 警惕“过度索引”诱发的写入劣化

大模型在看到一个复杂慢查询时，本能倾向于为所有 WHERE 条件和 JOIN 条件创建大而全的组合索引。

但是，单个表上的索引数量过多会显著增加 INSERT、UPDATE 操作的 I/O 负担，并导致索引碎片率迅速上升。拿到大模型的索引建议后，应当核对现有索引库，优先考虑改造已有索引，而不是无节制地新建索引。