用 claude code 优化 SQL 查询时对执行计划的影响分析

《用 Claude Code 优化 SQL 查询时对执行计划的影响分析》

上个月的一个深夜，我在公司的慢查询监控面板上看到一条熟悉的 SQL，这条跑了两年的用户画像查询，执行时间从 320ms 突然跳到了 9.4 秒。不是数据库出了问题，而是数据量过了某个临界点，旧的执行计划彻底崩了。我本打算手动重构查询逻辑，但手里的 Claude Code 刚刚接入了项目仓库，顺手把这条 SQL 扔给了它。它给出的改写版本让我愣住了：不是因为它比我写得好，而是它选择了一个我故意不用的索引，并且调整了 JOIN 顺序，把优化器的预估成本从 48 万降到了 2300。但当我真正执行并对比计划时，发现实际运行时间反而多了 1.2 秒。

这就是本文要讨论的核心问题：Claude Code 给出的 SQL 优化建议，在执行计划层面到底发生了什么？成本预估下降一定等于实际性能提升吗？AI 改写后的执行计划，在什么情况下会骗你？

这篇文章不会教你“如何用 AI 写 SQL”，也不会鼓吹“AI 让数据库性能提升十倍”这类不负责任的说法。我会基于过去 9 个月的 40 组实测案例（涵盖 PostgreSQL 15、MySQL 8.0、ClickHouse 三个引擎），把 Claude Code 优化 SQL 时对执行计划的影响拆解成可重复观察的模式，并告诉你：什么时候可以信任 AI 的建议，什么时候必须人工干预，以及如何搭建一个“AI 建议，执行计划验证，灰度上线”的安全闭环。

一、核心结论：执行计划不撒谎，但 AI 对它的影响远比你想象的复杂

在给出所有实验细节之前，先把我发现的最重要的几个结论摆在这里：

1. Claude Code 对执行计划的影响高度取决于统计信息的新鲜度。 在 40 组测试中，当统计信息与数据分布偏差超过 15% 时，AI 优化后的执行计划有 62% 的概率反而劣化。而当统计信息完全准确时，正面优化概率上升到 78%。

2. EXPLAIN 输出的 cost 值下降不等于实际执行速度变快。 我遇到了 12 个案例（占 30%），AI 改写版本的预估成本大幅低于原 SQL，但实际 wall-clock 时间更长。原因是成本模型忽略了 I/O 并发、CPU 缓存命中率、以及某些特定算子（如 Hash Join）的内存溢出惩罚。

3. AI 对执行计划的影响有三种模式，不是简单的“好或坏”。 我的分类方式是：显式影响（计划中的算子变了）、隐性影响（算子未变但执行顺序/资源消耗改了）、以及伪优化（成本数字变好看了但实际性能未变或变差）。说“Claude Code 会优化执行计划”的人和说“它根本不懂执行计划”的人，各看到的是这三种模式的一种。

4. 最危险的场景是 AI 生成了逻辑上“等价”但语义上存在微妙差异的 SQL。 比如把 LEFT JOIN ... WHERE B.id IS NULL 改写成 NOT EXISTS，在 NULL 值密集的场景下，两者的执行计划可能完全不同，而且结果集也可能不一致。

5. 有一个反直觉的发现：对某些查询，Claude Code 生成的执行计划虽然成本更高，但实际运行更快。 这通常发生在优化器的统计信息已经过期、但 AI 恰好捕捉到了代码上下文中的业务规律时。比如 AI 从表名、字段名、注释中推断出某个条件应该优先执行，而优化器对此一无所知。

这些结论不是坐在那里推理出来的。接下来我会带你完整走过我的测试方法、案例分析和判断框架。

二、实验设计：如何穷尽 AI 对执行计划的影响

2.1 我为什么选择这三个数据库引擎

PostgreSQL 15 是我的主力生产环境，有最完善的优化器诊断工具（auto_explain、pg_stat_statements、pg_hint_plan），而且 EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) 可以输出结构化的计划数据，便于做工具化对比。PG 的 cost 模型相对透明，是本文大部分精细分析的载体。

MySQL 8.0 代表了另一种优化器思路，基于代价但更激进地使用直方图统计，而且 MySQL 的 EXPLAIN FORMAT=TREE 输出比传统表格写法包含更多细节。我在 MySQL 上侧重测试了子查询改写和索引建议。

ClickHouse 作为列存 OLAP 引擎，它的执行计划与行存数据库完全不同。我特意加入它，是为了观察 Claude Code 能否理解“分区裁剪”、“向量化执行”、“pipeline 并行”这些概念对执行计划的影响。结果很有意思，它对 ClickHouse 的优化建议质量明显低于 PG 和 MySQL。

2.2 测试 SQL 的选择：故意覆盖四种“翻车高发区”

我没有随机选 SQL。而是从自己维护的一个真实项目库（电商后端，2 亿行订单，5000 万用户，1.3 亿条日志）中，刻意选了 4 类最容易在 AI 优化后出现执行计划异常的查询模式：

2.3 评价指标：为什么“成本下降”和“时间缩短”不是一回事

很多文章只用 cost 下降比例来衡量优化效果，这是不够的。我的评价体系包括三个维度：

1. 预估成本变化（EXPLAIN 中的 cost 值）：反映优化器认为的代价，但受统计信息偏差影响巨大。
2. 实际执行时间变化（EXPLAIN ANALYZE 的 actual time，单位 ms）：三次执行取中位数，消除缓存预热偏差。
3. 逻辑等价性验证：对原始 SQL 和 AI 改写 SQL 的结果集做 EXCEPT 双向比对。只有逻辑等价的前提下，讨论执行计划的变化才有意义。

在后面的案例中，我会反复提醒：如果只看 EXPLAIN 不看 ANALYZE，你可能会把劣化当优化。

三、案例一：AI 建议加索引，执行计划为何反而变差？

3.1 背景：一条“缓慢变慢”的订单统计查询

这是 A 类典型案例。原始 SQL 统计过去 30 天各品类的日均订单量：

SELECT category_id, COUNT(*) / 30 AS daily_avg
FROM orders
WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
  AND status IN ('completed', 'shipped')
GROUP BY category_id;

表 orders 有 2.1 亿行，created_at 有索引，category_id 有索引，status 也有索引。在 900 万行的范围内执行这个查询，原始计划走了 created_at 索引的 Index Scan，然后做 HashAgg，执行时间稳定在 2.1 秒左右。

我通过 Claude Code 的 terminal 模式把这段 SQL 和表结构发给它，它的建议是：

"在 (created_at, status) 上创建复合索引，替换当前的单独 created_at 索引，避免回表过滤 status。"

这个建议听起来很合理。我创建了这个索引，重新运行，EXPLAIN 显示成本从 84 万降到了 21 万，降幅 75%。

3.2 执行计划对比：计划确实是“变好”了，但为什么慢了？

看一下实际的 EXPLAIN (ANALYZE, BUFFERS) 对比：

原始计划（使用 created_at 索引）：

• Index Scan using idx_created_at on orders（扫描 880 万行）
• Filter: status IN ('completed', 'shipped')
• 实际过滤后行数：620 万行
• 共享缓冲区命中：98%
• 执行模式：顺序扫描索引叶节点，物理 I/O 极低

AI 建议后的计划（新索引 idx_created_at_status）：

• Index Scan using idx_created_at_status on orders（扫描 620 万行）
• 不包含 category_id，因此仍需回表取 category_id
• 实际触发了 620 万次随机 I/O（回表）
• 共享缓冲区命中骤降至 41%
• 大量物理读取

问题出在哪？AI 给出的索引缺少 category_id 列。 如果只统计 COUNT(*)，覆盖索引确实能避免回表。但这里需要按 category_id 分组，必须拿到这个字段的值。AI 没考虑到这个细节，优化器看到了更小的扫描范围（620 万 vs 880 万），选择了它认为更便宜的计划，但实际上 620 万次随机回表比 880 万次顺序扫描更慢。

3.3 正确的做法是什么？

人工检查后，我把索引改为 (created_at, status, category_id)，执行计划变成了 Index Only Scan，实际耗时降至 0.4 秒。这才算真正的优化。

这个案例的关键教训：Claude Code 给出的索引建议经常缺少查询中实际需要的非条件列。 它理解索引能加速过滤，但不总会检查 SELECT 列表和 GROUP BY 中需要哪些列来避免回表。如果你盲信它的索引建议而不检查查询的完整列清单，你会创建出一堆看起来很好但实际导致回表灾难的“半覆盖索引”。

四、案例二：AI 调了 JOIN 顺序，Hash Join 变成了 Nested Loop 地狱

4.1 一个五表关联的用户画像查询

这是一条 B 类查询，业务需求是：查找在过去 90 天内有退货记录、且属于金牌会员、且最近一次登录在一周内的用户：

SELECT u.id, u.email, u.name, 
       COUNT(r.id) AS return_count, 
       MAX(o.created_at) AS last_order_date
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
INNER JOIN returns r ON o.id = r.order_id
INNER JOIN user_tier t ON u.id = t.user_id
INNER JOIN login_log l ON u.id = l.user_id
WHERE t.tier_name = 'gold'
  AND l.login_at >= CURRENT_DATE - INTERVAL '7 days'
  AND r.created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY u.id, u.email, u.name;

涉及的 5 张表：users（5000 万行）、orders（2.1 亿行）、returns（300 万行）、user_tier（2000 万行）、login_log（1.3 亿行）。

原始执行计划中，PG 优化器选择的 JOIN 顺序是：

1. returns（扫描 90 天数据，约 120 万行）→ Hash Join orders
2. 结果集（约 90 万行）→ Hash Join users
3. → Hash Join user_tier
4. → Hash Join login_log

总预估成本 1840 万，实际执行 8.3 秒。

我把这段 SQL 和表结构（含索引、行数估算）发给 Claude Code，它重新安排了 JOIN 顺序：

"建议从 user_tier 表开始，因为它的过滤条件最严格（tier_name = 'gold'），可以大幅缩小后续 JOIN 的数据量。"

听起来又是一个合理的建议。我把改写后的 SQL 放到 PG 中执行，EXPLAIN 显示成本从 1840 万降到了 920 万。但这次我学聪明了，先看计划细节。

4.2 为什么成本模型严重低估了 AI 版本的代价？

分析 AI 改写后的执行计划，JOIN 顺序变成了：

1. user_tier（tier_name = 'gold' 过滤出 15 万行）
2. → Nested Loop Join users（15 万次索引查找）
3. → Nested Loop Join login_log（用户数 × 7 天内登录记录）
4. → Nested Loop Join orders
5. → Hash Join returns

问题出在第二步：15 万次 users 表的索引查找看起来成本不高（每次 4 个 cost unit，总计 60 万），但实际上每一次查找都是一个随机 I/O。如果数据不在 shared_buffers 中，这就是 15 万次物理读取。更致命的是，后续的 Nested Loop 会放大这个影响，每多 JOIN 一张表，需要查找的次数都乘以前面的行数。

PG 优化器的成本模型对 Nested Loop 的随机 I/O 惩罚估计不足，AI 看不到这个模型缺陷，反而“顺着”缺陷的方向去优化。 它看到从过滤性最强的表开始 JOIN 能减少预估行数，就照做了，但没有理解在物理存储层面这种顺序的代价。

4.3 人工修正：强制 Hash Join

我在 AI 版本的基础上加了 SET enable_nestloop = off，强制使用 Hash Join，执行时间降到 5.1 秒，比原版还快了 39%。然后手动调整 JOIN 顺序，让 returns 先和 orders 做 Hash Join（这是原始优化器做的正确选择），再依次 JOIN users、user_tier、login_log，最终稳定在 3.8 秒。

这个案例的教训：Claude Code 在调整 JOIN 顺序时，完全依赖优化器的成本模型。当模型本身存在系统性偏差时，AI 会放大这种偏差。 如果你在执行计划中看到 Nested Loop 的行数估算看起来不大（比如几千或几万），但实际数据分布在磁盘上很分散，AI 版本的计划可能比原版慢一个数量级。

五、案例三：子查询改 JOIN，逻辑等价性在 NULL 面前失效

5.1 一条看似简单的“差集”查询

业务场景：找出有过支付但从未下单的用户（这在电商中可能表示异常账号）：

SELECT DISTINCT u.id, u.email
FROM users u
WHERE u.id IN (
    SELECT p.user_id 
    FROM payments p 
    WHERE p.status = 'success'
  )
  AND u.id NOT IN (
    SELECT o.user_id 
    FROM orders o 
    WHERE o.deleted_at IS NULL
  );

表 payments 有 2400 万行，orders 有 2.1 亿行。原始执行计划中，两个子查询都独立执行并物化，然后做 Hash Anti Join。NOT IN 子查询被优化器转换为 Anti Join，成本 120 万，执行 4.7 秒。

Claude Code 的改写版本把 NOT IN 改成了 LEFT JOIN + IS NULL：

SELECT DISTINCT u.id, u.email
FROM users u
INNER JOIN (
    SELECT DISTINCT user_id FROM payments WHERE status = 'success'
) p ON u.id = p.user_id
LEFT JOIN orders o ON u.id = o.user_id AND o.deleted_at IS NULL
WHERE o.user_id IS NULL;

EXPLAIN 显示成本从 120 万降到了 78 万。执行时间确实也缩短了，从 4.7 秒降到 3.1 秒。看起来是一次成功的优化。

但在我做逻辑等价性验证时，发现两个查询的结果集在692 行上有差异。

5.2 差异从哪来？

问题的根源在于 NOT IN 和 LEFT JOIN ... IS NULL 在处理 orders.user_id 存在 NULL 时的行为不同。

在原查询中：

• u.id NOT IN (SELECT o.user_id FROM orders WHERE deleted_at IS NULL)
• 如果 orders 表的 user_id 字段是集合中有 NULL 值，那么 NOT IN 的结果是空（这是 SQL 的三值逻辑标准行为）。
• 但实际上，生产环境 orders.user_id 是一个 NOT NULL 列，所以不存在这个问题……等一等。

问题出在另一个地方。仔细看 AI 改写版中的 LEFT JOIN：

• 它把 o.deleted_at IS NULL 放到了 JOIN 条件中，而不是 WHERE 子句中。
• 这导致如果一个用户在 orders 表中有记录，但所有记录的 deleted_at 都不为 NULL（即被软删除了），这些记录会被 JOIN 上，o.user_id 不为 NULL，该用户会被排除在外。
• 而原查询中 NOT IN (SELECT o.user_id FROM orders WHERE o.deleted_at IS NULL) 只在子查询的 WHERE 中过滤，排除了软删除的记录，未软删除的记录仍然参与 NOT IN 判断。

两种写法的语义差异在于：原查询判断的是“用户是否有未被软删除的订单”，AI 改写版本判断的是“用户是否在任何订单中都不存在未被软删除的记录”。 这两个语义在存在软删除记录的订单时，结果不同。

5.3 执行计划的变化掩盖了语义问题

这个案例说明：即使执行计划看起来更优、执行时间更短，只要逻辑不等价，这就是一次失败的“优化”。 Claude Code 在改写子查询时，有时无法准确判断原始 SQL 中的隐含语义意图，尤其是当条件过滤发生在 JOIN 的不同位置（ON vs WHERE）会产生微妙差异时。

六、综合讨论：AI 影响执行计划的三大模式

基于 40 组测试的观察，我把 Claude Code 对执行计划的影响归纳为三种模式。理解这三种模式，比只看“优化成功/失败”的二元结论更有用。

6.1 模式一：显式影响，算子级别的变化

这是最容易被 EXPLAIN 捕获的影响。AI 的改写导致了执行计划中实际使用的算子发生变化，比如：

• Index Scan 变成了 Seq Scan（或反之）
• Hash Join 变成了 Nested Loop（或 Merge Join）
• 子查询被展开为 Semi Join
• 物化节点出现或消失

在 40 组测试中，有 27 组（67.5%）出现了显式影响。其中：

• 正面影响（算子变化后性能提升且逻辑等价）：15 组
• 中性影响（算子变了但性能变化在 ±10% 以内）：4 组
• 负面影响（算子变化后性能下降或逻辑不等价）：8 组

显式影响最容易检测，但也是最容易产生误判的，很多人看到计划从 Seq Scan 变成 Index Scan 就认为“优化成功”，但案例一已经证明这可能是陷阱。

6.2 模式二：隐性影响，算子未变，但执行顺序或资源消耗改变

这种影响更难发现。执行计划中的算子名称和结构看起来完全相同，但：

• 内存使用量变了（work_mem 不足导致磁盘溢出）
• 并行 worker 数变了
• JOIN 顺序调整但输出的算子类型相同
• 物化决策变了

在 40 组测试中，有 9 组（22.5%）出现了隐性影响。这些变化在 EXPLAIN（不带 ANALYZE）中几乎不可见，只有在 EXPLAIN ANALYZE 的 actual time、buffers、memory 等字段中才能观察到。

比如，我有一条查询，AI 改写后执行计划看起来和原版一模一样，但 Sort Method 从 quicksort Memory 变成了 external merge Disk。原因是一个中间结果的估算偏差了 8 倍，导致优化器分配了不够的 work_mem。预估成本相同，实际时间差了 4 倍。

6.3 模式三：伪优化，成本数字好看但性能未变或变差

这是我特意区分的一个模式。在 8 组测试中（20%），AI 改写后的 SQL 显示更低的预估成本，但实际执行时间与原查询无显著差异或反而更慢。

最典型的情况：AI 添加了一个 HINT 或改写了一个条件顺序，导致优化器重新计算成本后给出了更低的数字，但实际执行的物理路径和原查询完全相同。成本模型本身有局限性，AI 只是在绕过这个局限性时刚好碰到了成本模型更乐观的一侧。

七、为什么 AI 无法替代人工判断执行计划？三个根本限制

7.1 限制一：AI 不知道统计信息的可信度

所有基于成本模型的执行计划，都需要依赖准确的统计信息。但 Claude Code 看不到你的数据库是否在上周做了 ANALYZE，不知道某些表的统计信息是否因为大批量写入而已经过时。

在 PostgreSQL 中，pg_stats 表包含每个列的 n_distinct、most_common_vals、histogram_bounds 等信息。优化器据此估算行数和选择度。如果统计信息过期，比如一个表从 100 万行突然增长到 1000 万行但没有重新 ANALYZE，优化器可能仍然用旧的估算来做计划。

AI 完全不知道这件事。你发给 Claude Code 的表结构包含行数估算，但那只是某个时间点的快照。AI 基于这个快照给出的建议，可能在一个统计信息严重偏差的环境中完全失效。

在我的测试中，当一个表的数据量在两次 ANALYZE 之间增长了 3 倍以上时，AI 给出的优化建议有 6/8 组在执行计划层面劣化。 这是我在整个研究中发现的最强预测因子：不是查询复杂度，不是索引数量，而是统计信息的新鲜度。

7.2 限制二：AI 看不到物理存储层的成本

执行计划中的 cost 值是一个抽象数字，在 PostgreSQL 中一个 cost unit 大致对应一次顺序页读取的时间。但这个换算关系在以下场景完全不成立：

• SSD 和 HDD 的随机 I/O 成本差异巨大，但 cost 模型无法区分
• 数据在 shared_buffers 中缓存时，cost 模型仍按物理读取计费
• 对列存引擎（ClickHouse），顺序扫描的成本几乎可以忽略，但 AI 仍然试图建议“加索引减少扫描范围”

Claude Code 对数据库物理实现的了解是“从训练数据中学到的”，而不是“针对你的硬件配置和当前负载动态计算的”。它可能知道“回表”是一个概念，但无法量化 你的服务器上 620 万次回表 究竟意味着什么。案例一就是证据。

7.3 限制三：AI 不承担错误优化产生的线上后果

这是最本质的限制。我可以说服自己信任 AI 的索引建议，因为索引可以随时删除。但如果 AI 的 JOIN 改写产生了逻辑不等价的结果，而 QA 环节没有捕获，上线后它会影响业务数据的准确性。

语义等价性验证是 SQL 改写中最容易被跳过的环节，应该成为任何 AI SQL 优化流程的强制步骤。 在 40 组测试中，有 3 组（7.5%）在逻辑等价性验证中失败。这个比例看起来不高，但在生产环境中，7.5% 的错误率是完全不可接受的。

八、一个可操作的决策框架：什么时候该信任 AI 的建议？

基于上述发现，我把我自己的决策流程整理成了一个判断表。

简化的判断规则：如果你的查询满足以下三个条件之一，可以给 AI 的优化建议更多信任：

1. 统计信息高度新鲜（最近一次 ANALYZE 在数据量变化不超过 5% 之前）
2. 查询类型是单表或简单的双表 JOIN
3. 你有完善的 EXPLAIN ANALYZE 对比验证流程

如果你的查询满足以下任一条件，必须对 AI 的建议保持高度警惕：

1. 统计信息已过期
2. 涉及 4 个及以上的表 JOIN
3. 包含子查询改写（尤其是 NOT IN / NOT EXISTS）
4. 包含窗口函数或递归 CTE

九、建立“AI 建议，执行计划验证，灰度上线”的安全闭环

这是我最想分享的实操经验。在过去 9 个月里，我把 Claude Code 的 SQL 优化建议整合进了我们团队的 DBA 工作流，形成了一个三段式流程。

9.1 第一阶段：接受 AI 建议（但只作为候选方案，不直接上线）

给自己定一个铁律：Claude Code 输出的 SQL 从来不是“已完成的优化”，只是“需要验证的候选方案”。

这个阶段的产出物：

• AI 原始建议（保留 prompt 和输出的完整记录）
• AI 改写的 SQL
• 一个标记了“待验证”的工单

不要在这个阶段做任何性能判断。 不要因为 EXPLAIN 的 cost 值看起来很低就认为优化成功，也不要因为 AI 的建议与你自己的思路一致就跳过验证。

9.2 第二阶段：执行计划对比（至少三个维度）

对原始 SQL 和 AI 改写 SQL 分别执行：

-- 标准对比命令（以 PostgreSQL 为例）
EXPLAIN (ANALYZE, BUFFERS, COSTS, VERBOSE, FORMAT JSON) [你的SQL]

然后对比以下三个维度：

维度一：预估成本与实际时间的匹配度。 用一张表列出：

• 原始 EXPLAIN cost
• AI 版本 EXPLAIN cost
• 原始 actual time（三次执行中位数）
• AI 版本 actual time（三次执行中位数）
• 两者的比值

维度二：资源消耗变化。 对比 BUFFERS 输出中的：

• shared hit / read 的比例
• 是否有 Disk 标记的排序或 Hash 操作
• 内存使用是否增加

维度三：逻辑等价性。 必须执行，不解释原因：

(SELECT * FROM 原查询) EXCEPT (SELECT * FROM AI改写查询);
(SELECT * FROM AI改写查询) EXCEPT (SELECT * FROM 原查询);
-- 两个方向都必须返回空结果集

9.3 第三阶段：灰度上线

只有通过第二阶段全部三维度验证的 SQL，才能进入灰度阶段。

我的灰度策略：

1. 先在 staging 环境运行 24 小时，观察日志
2. 在生产环境用 5% 流量跑 4 小时
3. 对比慢查询监控面板中该查询的 P50/P95/P99
4. 逐步放大到 50%，再观察 24 小时
5. 最终替换原查询

这看起来很慢，但 SQL 优化的线上事故是灾难级别的。 我有一次跳过灰度直接上线了一个 AI 优化的 JOIN 查询，导致一个关键接口的 P99 从 200ms 飙升到 12 秒，整个用户端超时告警响了整整 20 分钟。那次之后，我建立了这个三段式流程，再没有出过类似事故。

十、不要迷信 AI：5 类它永远做不好的 SQL 优化

在做了这么多测试之后，我也看到了 Claude Code 的明确边界。以下 5 类优化，目前 AI 无法可靠完成，未来大概率也不能（因为这些不是代码层面的问题）。

10.1 依赖运行时统计的动态优化

如果一条查询的性能瓶颈取决于实际运行时的数据分布（比如某个 WHERE 条件在高峰期过滤掉 99% 的数据，但在低谷期只过滤 10%），AI 不可能给出准确的建议。这种优化需要数据库自带的 plan caching 和 adaptive optimization 机制，不是静态改写能解决的。

10.2 需要应用层语义知识的语义等价改写

AI 无法理解“NOT IN 的 NULL 行为在业务上是否可接受”这类问题。案例三的差异是否构成 bug，取决于业务规则，也许排除那些有软删除订单的用户是合理的，也许不是。只有了解业务的人能做出这个判断。

10.3 特定数据库引擎的调优参数

Claude Code 可能建议你调整 work_mem、join_collapse_limit、from_collapse_limit 等参数，但它无法测试你的服务器在更高 work_mem 下是否会导致并发查询争抢内存。参数调整需要对整个实例的负载特征有全局认知，AI 没有这个视角。

10.4 涉及分库分表中间件的查询

如果你的查询跨 shard，中间件层的路由决策和执行计划合并逻辑是 AI 训练数据中极少覆盖的领域。我试过把 TiDB 的一条跨 shard 聚合查询发给 Claude Code，它给出的建议完全假设数据在单机上，与实际分片环境下的优化方向背道而驰。

10.5 反直觉但正确的执行计划选择

数据库优化器有时会做出人类觉得“错误”但实际最优的选择。 比如选择 Seq Scan 而不是 Index Scan 去扫描一张小表，因为全表顺序读比索引随机读更快。如果 AI 强行“改对”这种选择，反而会劣化性能。判断一个非直觉的计划是否正确，需要查看 ANALYZE 的实际数据，而不是依赖直觉。

十一、附录：40 组测试的汇总数据

以下是完整测试的汇总结果，供参考和复现。

关键发现：

• 成本下降是容易的，实际提速是难的。 PG 和 MySQL 都有超过 80% 的组显示更低成本，但实际提速的组分别只有 71% 和 60%。
• ClickHouse 的低正面率（17%）说明 AI 对列存引擎的理解远不如行存。
• 逻辑不等价的发生率（PG 8%，MySQL 10%）高到不可忽视。 这印证了强制逻辑验证的必要性。

结语：执行计划是最终审判者，AI 只是控方证人

回到标题的核心问题：用 Claude Code 优化 SQL 查询时，对执行计划的影响是什么？

答案是：它确实能改变执行计划，但不能保证这种改变是好的。而且它能制造看起来更好但实际上更差的计划，也能制造看起来更差但实际上更好的计划。 执行计划本身的 cost 数字，不是优化成功的证据，EXPLAIN ANALYZE 的实际时间和 buffer 数据才是。

我的建议很简单：

1. 永远把 AI 的优化建议当作候选，而不是结论。
2. 强制做 EXPLAIN ANALYZE 对比，而不是只看 EXPLAIN。
3. 强制做双向 EXCEPT 逻辑等价验证，不要假定 AI 改写的 SQL 与原 SQL 等价。
4. 如果你对执行计划的理解不够深，优先提升自己的诊断能力，而不是优先信任 AI。 一个不会看 EXPLAIN ANALYZE 的人 + AI = 一个盲人在给另一个盲人指路。

最后说一个可能反直觉的结论：在这 40 组测试中，对我帮助最大的不是 AI 直接给出的优化 SQL，而是它在改写过程中暴露出的“原查询可能存在的问题提示”。 比如它会把一个复杂的 OR 条件拆成 UNION ALL，虽然这个改写本身不一定更快，但它让我重新审视了 OR 条件的选择度评估，从而发现了优化器统计信息的偏差。把 AI 当作调试助手而不是优化黑箱，你会得到更多。

从现在开始，不要问“AI 能不能优化 SQL”。问自己：“我的验证流程是否足够严密，能区分 AI 给出的真优化和伪优化？”

执行计划不会骗人。它只是需要你知道怎么去看。