Claude Code 辅助编写数据库迁移脚本时对索引建立的建议是否可靠

上个月凌晨两点，我盯着pt-query-digest的输出，心里发凉。一条本该走覆盖索引的订单查询，在生产环境跑了 42 秒，把整个交易服务的连接池打满。而那个索引，正是前一天通过 Claude Code 生成的迁移脚本直接上线时，我偷懒没有二次确认的那一条。

这不是 Claude Code 的错。是我把“它能生成索引建议”和“它的建议可以直接用”划了等号。

过去半年，我在三个实际项目中系统性地测试了 Claude Code 在数据库迁移场景下的索引建议可靠性，从电商订单表到日志分析系统，再到一个 SaaS 租户隔离的数据模型。核心结论是：Claude Code 给出的索引建议，在“看一眼就能判断对不对”的简单场景下，可靠度约 80%；但在涉及复合索引设计、业务查询模式预判、写入性能权衡的复杂场景下，可靠度骤降至 30% 以下。它像一个读过所有官方文档但从未真正管过生产库的实习生，基础扎实，判断力不足。

这篇文章，就是我从这半年的测试、踩坑、复盘里挖出来的完整判断框架。我不会告诉你“Claude Code 很厉害”或“它不靠谱”这种二元结论，而是把它的可靠性边界掰开揉碎，让你知道什么时候可以信任它，什么时候必须亲自上手。

一、先给结论：Claude Code 的索引建议，是一个“80 分提示器”，不是一个“决策者”

在深入具体场景之前，我先把这个结论讲透。

为什么叫“80 分提示器”？ 因为 Claude Code 在识别“这张表缺了哪个明显的索引”、“这个查询应该走哪个索引”这类问题上，表现接近一个熟练的中级开发工程师。它能从给定的 SQL 语句、表结构定义中，判断出常见的索引缺失和冗余问题。但它的建议从来不应该被直接执行，每次都需要一个有经验的 DBA 或后端工程师审核，原因有四个层面：

第一，Claude Code 看不到数据分布。 它只能分析你给它的表结构 DDL 和查询语句，它不知道你的表里 90% 的status字段值是“已完成”，而“待支付”只占 0.1%。当一个查询WHERE status = '待支付'时，索引idx_status是否有价值，完全取决于这个值的基数。Claude Code 的默认建议通常是“给 WHERE 条件里的字段都建索引”，但真实世界的索引策略从来不是这样。

第二，Claude Code 不关心写入成本。 每一次我让它生成迁移脚本时，它都倾向于多建索引，“宁可多不可少”的策略。这在读多写少的报表库或许还行，但在写入峰值 8000 TPS 的订单表上，多一个索引意味着每次INSERT要多维护一个 B+Tree，写入耗时增加 30%-50%。

第三，Claude Code 不了解你的查询负载构成。 它不会知道，在凌晨 2 点到 4 点之间，有一个定时任务每秒扫 200 万行做对账；也不会知道某条 SQL 虽然代码里写了但实际线上从不执行。它只能基于你喂给它的局部信息做判断，而索引优化从来是需要全局视角的。

第四，Claude Code 对不同数据库版本优化器的差异化行为缺乏认知。 它在 MySQL 5.7 和 MySQL 8.0 的索引建议几乎一模一样，但任何一个做过版本迁移的 DBA 都知道，两者的优化器在直方图统计、不可见索引、降序索引上的行为差异足够让同样的索引产生截然不同的执行计划。

所以，把 Claude Code 的索引建议看作一个“提示器”是正确的定位：它帮你快速想起那些你可能遗漏的索引，但最终要不要建、怎么建，必须由你来判断。

二、我是怎么测试的：三个真实场景，六轮对比验证

说结论之前，必须先交代测试方法。这不是实验室里的玩具测试，而是三个实际生产项目的迁移场景。

场景 A：电商订单核心表（高并发写入）

某电商平台订单主表orders，日均写入 300 万行，峰值 TPS 约 7500。表结构包含 42 个字段，已有 11 个索引。业务上有三类高频查询：（1）按user_id + create_time查用户订单列表；（2）按order_status + paid_time查待处理订单；（3）按merchant_id + order_status + create_time查商家后台订单。

我让 Claude Code 读取了完整的 DDL 和典型查询语句，让它生成迁移脚本，包括索引建立建议。

场景 B：日志聚合分析表（高吞吐读取）

一个 ELK 替代方案中的日志存储表app_logs，日均写入 1.2 亿行，保留最近 7 天数据。典型查询是按trace_id查单次请求链路，按service_name + log_level + timestamp查错误日志。表上最初只有主键索引。

场景 C：SaaS 租户隔离模型（复合主键设计）

多租户 SaaS 的客户数据表tenant_customers，使用tenant_id + customer_id作为复合主键。业务查询几乎全部带tenant_id条件。但有一些跨租户的数据统计分析查询，需要对created_date和customer_level进行聚合。

为什么选这三个场景？ 因为它们分别代表了数据库索引设计中最需要权衡的三种情况：写入敏感型（订单表）、读取密集型（日志表）、复合键设计型（SaaS 租户表）。单测一个场景得不出普遍结论。

在每个场景下，我分别执行了六轮测试，让 Claude Code 生成索引建议，然后将它与以下方案对比：

1. DBA 手工设计的索引方案（作为基准）
2. pt-duplicate-key-checker的冗余索引检查结果
3. EXPLAIN执行计划的真实效果
4. 模拟生产负载下的写入性能损耗

这六轮测试不是一次性跑完的，而是跨了三个月的迭代：从最初的“全自动信任”到“逐条验证”，再到“形成审核清单”。每一轮都让我更清楚地看到它的能力边界。

三、场景还原：Claude Code 在订单表上犯了什么错

先说场景 A 的详情，因为这里面的教训最密集。

3.1 Claude Code 给出的原始建议

我给的提示词是：“读取 orders 表结构，针对以下三条查询生成索引优化建议和迁移脚本。”然后附上了三条 SQL。Claude Code 返回了这样的建议：

-- Claude Code 建议新增
ALTER TABLE orders ADD INDEX idx_user_create (user_id, create_time);
ALTER TABLE orders ADD INDEX idx_status_paid (order_status, paid_time);
ALTER TABLE orders ADD INDEX idx_merchant_status_create (merchant_id, order_status, create_time);
ALTER TABLE orders ADD INDEX idx_create_time (create_time); -- "为了覆盖排序场景"

一共 4 个新索引。加上原有的 11 个索引，整张表将拥有 15 个索引。

看起来没什么问题，对吧？ 每个 WHERE 条件的字段组合都有了对应的复合索引，甚至还贴心地加了一个create_time单列索引应付排序。如果你在凌晨三点赶交付、身心疲惫地看到这份建议，你大概率会直接git add然后提交。

但当我把它交给 DBA 审核时，问题被逐个揪了出来。

3.2 问题一：idx_create_time是完全冗余的

idx_user_create这个索引的前缀列是user_id，但如果查询语句中user_id不是必填条件，而是一段代码中有“如果传了 user_id 就加条件，否则只按 create_time 排序”这种逻辑，Claude Code 就理解不了。它会假设idx_user_create能覆盖“只有 create_time”的查询，实际上不能。索引最左前缀原则决定了idx_user_create(user_id, create_time)在查询条件没有user_id时，优化器大概率不会用它来满足ORDER BY create_time。

但问题在于：如果那种代码逻辑并不存在呢？ Claude Code 只是在“以防万一”。它不知道实际的代码分支，它只会因为看到了ORDER BY create_time就自动追加一个索引。这种“自动追加”逻辑在它看来是尽责，在 DBA 看来是盲目。

3.3 问题二：三个复合索引中，有两个存在字段重叠

idx_status_paid(order_status, paid_time)和idx_merchant_status_create(merchant_id, order_status, create_time)都包含了order_status字段。如果业务上order_status的基数很低（只有 5 个枚举值：待支付/已支付/已发货/已完成/已取消），那么idx_status_paid本身的优化价值就很有限，除非paid_time能提供高选择性。而idx_merchant_status_create里的merchant_id已经是高选择性字段，后面再跟order_status的意义不大。

但 Claude Code 不理解“字段选择性”这个概念。它只知道“WHERE 条件里有这几个字段，那我把它们拼成复合索引”。这是它在所有场景下表现出的最大短板。

3.4 问题三：对写入成本的完全无视

原有的 11 个索引已经让每次INSERT操作涉及 12 次 B+Tree 写入（含主键）。加上 4 个新索引后变成 16 次。在我们测试环境用sysbench模拟 7500 TPS 写入负载时，对比前后的写入延迟：

DBA 的最终方案是：只增加idx_user_create(user_id, create_time)，修改已有的idx_status为idx_status_paid(order_status, paid_time)（覆盖原索引的同时增加列），删除一个实际未被使用的冗余索引idx_create_ip。总共保持 12 个索引。

这个对比数据很关键：Claude Code 多出来的三个索引，占用了 50% 的额外存储空间，却只在实际查询中贡献了 0.4% 的性能提升（因为大部分查询已经被现有索引覆盖），同时让写入延迟恶化了接近 60%。

四、日志表场景：当“索引全建”策略的短板被大数据量放大

场景 B 的日志表测试，暴露了另一个维度的问题：Claude Code 倾向于把“能想到的索引全建上”，这在数据量极大、写入压力极大的日志场景下是灾难性的。

4.1 它的建议清单

针对日志表app_logs，Claude Code 看到查询WHERE trace_id = 'xxx'后，建议：

ALTER TABLE app_logs ADD INDEX idx_trace_id (trace_id);
ALTER TABLE app_logs ADD INDEX idx_service_level_time (service_name, log_level, timestamp);
ALTER TABLE app_logs ADD INDEX idx_timestamp (timestamp);

三个索引，看起来依然合理。trace_id是典型的等值查询，service_name + log_level + timestamp是典型的组合过滤，timestamp是典型的时间范围查询。

但在我们日均写入 1.2 亿行的表上，这三个索引意味着：

• 每天新增的索引写入量约 3 × 1.2 亿 = 3.6 亿次 B+Tree 节点操作
• 索引占据的磁盘空间约等于数据本身的 1.8 倍
• 7 天的数据保留期意味着索引总大小将超过 500GB

4.2 实际查询模式分析

当我们拉出真实查询日志后发现：

• trace_id查询只占总查询量的 0.3%，且通常在请求超时排查时使用，不是常规路径
• service_name + log_level + timestamp查询占 92%，但log_level几乎总是ERROR（占 78%）或WARN（占 15%），选择性很低
• 单独按timestamp查询占 7%，且几乎都带service_name作为隐式过滤

所以 DBA 给出的方案是：

• 不建idx_trace_id（改为定时任务扫原始数据 + 归档到单独的 trace 专用表）
• 建idx_service_time(service_name, timestamp)，舍弃log_level列（因为基数过低，在索引里没有意义的过滤性）
• 利用 MySQL 8.0 的不可见索引特性，先在从库尝试idx_timestamp一周，确认无用后删除

Claude Code 完全没有能力做出这种“看查询频率占比决定取舍”的判断。 它假定所有给它的查询都同等重要，这种均匀化假设在真实生产环境中几乎从未成立。

五、SaaS 租户表的教训：Claude Code 不懂“隐式条件”

场景 C 是最让我警醒的，因为它犯的错误最容易在代码审查中被忽视。

5.1 表结构与查询

CREATE TABLE tenant_customers (
  tenant_id INT NOT NULL,
  customer_id BIGINT NOT NULL,
  customer_name VARCHAR(255),
  customer_level TINYINT,
  created_date DATE,
  PRIMARY KEY (tenant_id, customer_id)
);

-- 典型查询 1：租户内查客户
SELECT * FROM tenant_customers WHERE tenant_id = ? AND customer_id = ?;

-- 典型查询 2：跨租户统计
SELECT customer_level, COUNT(*) FROM tenant_customers WHERE created_date > ? GROUP BY customer_level;

5.2 Claude Code 的建议

它看到查询 1，认为主键已经覆盖，这是正确的。但看到查询 2 时，它建议：

ALTER TABLE tenant_customers ADD INDEX idx_created_level (created_date, customer_level);

这个索引的问题在于：在一个复合主键为tenant_id + customer_id的表上，任何不带tenant_id的索引，数据分布都极度依赖租户规模。 如果大租户 A 有 500 万客户，小租户 B 只有 100 个，那么idx_created_level扫描 A 的数据时需要过滤掉 B 的客户，但索引本身不包含tenant_id，优化器只能扫全索引再做回表过滤。

更重要的是：查询 2 是一个跨租户统计查询，它通常只在管理后台的日报里跑，执行频率极低。但 Claude Code 不知道这一点，它默认这个查询值得专门建一个索引。

DBA 的最终判断是：不建这个索引。跨租户统计改为异步任务，用离线表tenant_customers_stats基于tenant_id分批跑，结果汇总。这根本不是索引优化能解决的问题，而是查询设计本身需要被改变。 Claude Code 却当成索引问题来处理。

这是它最致命的盲区：它会假设所有给它的 SQL 都是合理且必须被优化的，而不会反问“这个查询是否应该存在”。

六、拆解 Claude Code 索引建议的常见误区

综合三个场景的测试结果，我把 Claude Code 在索引建议上最常犯的错误归纳为以下六类。这六个误区是我在逐条审核它的建议时反复遇到的，每一个都踩过坑。

误区一：WHERE 条件字段一定需要索引

这是 Claude Code 的默认行为。只要看到WHERE col = ?，它大概率会建议给col建索引。但它不判断：

• 这个字段的选择性是否足够高
• 这个查询的执行频率是否值得维护一个索引
• 是否已有其他复合索引能覆盖这个字段

真实案例： 订单表的order_status字段，只有 5 个值且分布极不均匀，95% 的订单处于“已完成”状态。建一个idx_status，查询WHERE order_status = '已完成'时优化器也会选择全表扫描而非走索引，因为这个索引的选择性差到比全表扫描还慢。但 Claude Code 依然建议建它。

误区二：复合索引的列顺序只是“WHERE 条件的字段拼起来”

Claude Code 在决定复合索引的列顺序时，基本规则是“按查询中出现的顺序排列”。它不理解：

• 高选择性字段应该放在前面
• 等值条件字段应该放在范围条件字段之前
• 覆盖索引的设计需要考虑回表次数

真实案例： 日志表查询WHERE service_name = 'order' AND log_level = 'ERROR' AND timestamp > '2025-01-01'，Claude Code 建议的索引是(service_name, log_level, timestamp)。但log_level选择性极低（三个值），应放在最后甚至移除；timestamp是范围查询，应放在等值条件service_name之后。正确的设计是(service_name, timestamp)。

误区三：ORDER BY 和 GROUP BY 总是需要独立的索引

当查询同时有WHERE和ORDER BY时，Claude Code 有时会分开建两个索引，一个覆盖WHERE，一个覆盖ORDER BY。它不理解好的复合索引设计可以同时覆盖两者。

真实案例： SELECT * FROM orders WHERE user_id = ? ORDER BY create_time DESC。Claude Code 可能建议建idx_user_id(user_id)和idx_create_time(create_time)，但最优方案是idx_user_create(user_id, create_time)一个索引同时搞定过滤和排序。

误区四：认为索引越多查询越快

这个误区在日志表场景中体现得最明显。Claude Code 的索引建议数量通常在 3-5 个，几乎不考虑累积写入成本和存储开销。它没有“成本预算”的概念，不会在“查询加速”和“写入减速”之间寻找平衡点。

误区五：不懂业务逻辑中的“隐式条件”

SaaS 租户表是最典型案例。几乎所有查询都带tenant_id，但出于代码复用的原因，有些统计查询写的 SQL 里没有显式写tenant_id过滤，因为业务上“统计所有租户”也是需求。Claude Code 无法区分“这个查询不带 tenant_id 是因为不需要”还是“是因为遗漏了安全条件”。它只能按字面 SQL 处理。

误区六：对索引类型的理解过于单一

Claude Code 几乎只会建议 B-Tree 索引。在日志表需要全文索引的场景、GIS 数据需要空间索引的场景、JSON 字段需要虚拟列索引的场景下，它要么不提及，要么给出错误的类型建议。

七、Claude Code 在哪些情况下是可靠的

话说到这份上，如果你觉得我在全盘否定 Claude Code，那误会大了。我用了半年，它帮我在项目中节省的时间，保守估计在 30 小时以上。关键在于知道它在哪些场景下靠谱。

可靠场景一：识别明显的索引缺失

当你有一个查询跑得很慢，手写EXPLAIN一看是全表扫描，而WHERE条件里有个user_email字段根本没索引，这种场景，Claude Code 几乎 100% 能正确识别。它不需要理解数据分布，不需要权衡写入成本，只需要匹配“WHERE 条件字段 vs 现有索引列表”。

可靠度：接近 100%

可靠场景二：提示冗余索引

如果有两个索引分别是idx_a_b_c(a, b, c)和idx_a_b(a, b)，第二个其实是第一个的前缀，属于完全冗余。Claude Code 在扫描表结构时能稳定识别这种冗余。这类问题的判断逻辑清晰，不涉及数据分布或业务理解。

可靠度：约 90%

可靠场景三：生成索引审计清单

这是我认为 Claude Code 在数据库迁移中最有价值的用法，不是让它直接给建议，而是让它阅读你的迁移脚本和现有表结构，然后生成一份检查清单，告诉你：

• 哪些现有索引可能没被使用
• 哪些新索引可能和已有索引重叠
• 哪些查询在现有索引下可能有问题

这份清单本身不是决策，而是提醒事项。你把清单拿给 DBA，DBA 做最终判断。这个用法下，Claude Code 的角色是“辅助记忆”，不是“辅助决策”。

可靠场景四：简单的覆盖索引设计

当查询语句只涉及单表、单条件、字段数量少于 3 个，且明确要求“只需要索引不要回表”时，Claude Code 能正确设计覆盖索引。比如看到SELECT user_id, user_name FROM users WHERE email = ?，它能建议ALTER TABLE users ADD INDEX idx_email_cover(email, user_id, user_name)。这是标准模式，不需要什么判断力。

八、一个可复用的判断框架：如何审核 Claude Code 的索引建议

既然我们知道它在什么情况下可靠、什么情况下不可靠，下一步就是建立一套审核流程，让 Claude Code 的建议变成可验证、可追溯的输入，而不是黑盒输出。

以下是我经半年的试错后总结的五步审核法，每次拿到 Claude Code 生成的索引建议，我按顺序执行这五步：

第 1 步：用 EXPLAIN 验证每个建议索引的实际效果

不要只看 Claude Code 给出的解释。直接在测试库上ALTER TABLE加索引（或先建一个结构相同无数据的影子表），然后对每条目标查询执行EXPLAIN：

EXPLAIN FORMAT=JSON SELECT ...;

重点关注：

• type：是否为ref、range或index（ALL表示索引没被用上）
• key：优化器实际选择的索引是否是 Claude Code 建议的索引
• rows：预估扫描行数是否显著减少
• Extra：是否出现Using filesort、Using temporary（说明索引没覆盖排序或分组需求）

关键判断：如果 EXPLAIN 显示优化器没有选择 Claude Code 建议的索引，或者虽然选择了但扫描行数没有明显下降，该建议直接标记为无效。

第 2 步：用 pt-duplicate-key-checker 检查冗余

Percona Toolkit 里的pt-duplicate-key-checker是一个神器，三秒钟跑完整个库，输出所有冗余索引和重复外键约束。把 Claude Code 的建议索引加进去一起跑：

pt-duplicate-key-checker h=localhost,u=root,p=password,D=yourdb

如果输出的冗余关系里包括 Claude Code 建议的索引，立刻标记为需要合并或移除。

第 3 步：查阅慢查询日志，确认查询频率

Claude Code 最大的盲区就是不知道哪些查询高频、哪些低频。慢查询日志或sys.statement_analysis表能告诉你真实情况：

SELECT query_sample_text, 
       SUM_TIMER_WAIT / 1000000000000 AS total_sec,
       COUNT_STAR AS exec_count
FROM performance_schema.events_statements_summary_by_digest
WHERE query_sample_text LIKE '%target_table%'
ORDER BY total_sec DESC;

关键判断：如果一个索引只是为了优化一个执行频率极低（每天几次）的查询，但给高并发写入增加了永久负担，那么这个索引的净收益为负，应拒绝。

第 4 步：评估写入性能影响

在测试环境用sysbench或自建脚本模拟写入负载，对比加索引前后的INSERT/UPDATE延迟。以订单表为例：

sysbench /usr/share/sysbench/oltp_insert.lua \
  --mysql-host=127.0.0.1 --mysql-user=root --mysql-password=xxx \
  --mysql-db=test --tables=1 --table-size=10000000 \
  --threads=32 --time=300 run

分别在有 Claude Code 建议索引和没有的情况下运行，记录 P99 延迟差异。

关键判断：如果 P99 写入延迟增加超过 30%，需要重新评估该索引的必要性，除非该索引对应的查询性能提升幅度极大（如从 10 秒降到 0.1 秒）。

第 5 步：执行“业务逻辑审查”

这一步没有工具能替代，需要人工完成。针对 Claude Code 建议的每一个索引，回答三个问题：

1. 这个索引对应的查询，业务逻辑是否正确？（还是查询本身写错了该去掉）
2. 这个索引依赖的字段，是否存在隐式条件？（如 SaaS 表必须有租户隔离）
3. 未来 6 个月内，这个表的数据量增长预测如何？（如果预计增长 10 倍，索引维护成本是否会从“可接受”变成“不可接受”）

九、当我在 ChatGPT / Claude / Gemini 之间对比索引建议质量时

既然这个话题是 AI 辅助数据库迁移，那我不可能只测一个模型。同样的三个场景，我用 ChatGPT-4o（Web 版）、Gemini 2.5 Pro（API）、和一个开源模型 DeepSeek-V3 都跑了对比测试。

以下结论完全基于我的个人测试，不代表官方基准。

整体排名（索引建议质量）

Claude Code 的独特优势

Claude Code 相比其他模型最突出的一个特点是：它对现有索引的“读取”和“理解”能力更强。 当给足表结构 DDL 和现有的所有 CREATE INDEX 语句时，Claude Code 能更准确地判断“新增索引是否会与已有索引构成冗余”。ChatGPT 在这方面偶有遗漏，Gemini 表现中等，DeepSeek 经常需要多次纠正。

ChatGPT-4o 的独特优势

ChatGPT-4o 在复合索引的列顺序设计上比 Claude Code 更优。它会主动分析 WHERE 条件中字段的选择性，并把等值条件放在范围条件之前。在订单表的测试中，ChatGPT-4o 建议的idx_merchant_create(merchant_id, order_status, create_time)中，明确指出order_status的基数可能影响索引有效性，建议用SELECT COUNT(DISTINCT order_status) FROM orders确认。这种“先质疑、再建议”的风格比 Claude Code 的“直接给建议”更安全。

Gemini 2.5 Pro 的独特优势

Gemini 对 MySQL 和 PostgreSQL 优化器的版本差异有一定区分能力。当你指定PostgreSQL 16时，它会提及 BRIN 索引对时间序列表更适合、部分索引可通过WHERE子句限制行数，而 Claude Code 通常只会给 B-Tree 建议。这个差异在对日志表这种时间序列场景下非常关键。

测试中发现的共性缺陷

所有模型都有将GROUP BY字段自动加入索引的建议倾向，且都不评估GROUP BY是否需要“索引覆盖以避免临时表”。 报表查询中常见的GROUP BY date, category会触发模型建议idx_date_category(date, category)，但优化器在使用这个索引做GROUP BY时仍然可能出现Using temporary; Using filesort，因为索引本身需要完全覆盖分组字段的排序要求。没有一个模型能清楚地解释这个机制。

另外一个所有模型共有问题是：没有一个模型主动要求提供数据分布信息或慢查询日志。 它们都满足于“你给我 SQL 和表结构，我给你索引建议”，而不是追问“这条查询线上跑了多少次？过滤后的数据量是多少？”。

十、行动建议：不同场景下的使用策略

到这里，终于可以给出分场景的行动指南了。根据你的项目类型、团队配置和时间压力，选择不同的策略。

策略 A：有专职 DBA，时间充裕

使用方式：让 Claude Code 生成“索引审计清单”，不给直接建议。

提供给 Claude Code 的内容：

• 完整的表 DDL（包括所有现有索引）
• 最近的慢查询日志摘要（pt-query-digest输出）
• 预期的未来查询模式描述

让 Claude Code 输出的不是 ALTER TABLE 语句，而是：

1. “以下查询在现有索引下可能执行全表扫描”
2. “以下现有索引可能是冗余的”
3. “以下查询可能需要一个新的复合索引，但不能确定列顺序”

然后把这份清单交给 DBA，DBA 在一个小时内复核完成。这是在实际项目中效率最高的用法，也是我目前在三四个项目中采用的模式。

策略 B：没有 DBA，开发自管数据库

使用方式：Claude Code 生成建议 + 严格执行五步审核法。

没有 DBA 的团队，最大的风险不是“索引建少了”，而是“索引建错了但没人发现”。你必须自己完成五步审核，尤其是第三步和第四步，查询频率确认和写入性能评估。

一个现实建议：给自己定一个铁律，Claude Code 建议的索引，在审核通过之前，永远先建在从库或测试库，观察一周的慢查询日志和写入延迟后，再上生产主库。 不要因为“看起来合理”就省掉这个观察期。我订单表翻车那次，就是省了这一步。

策略 C：赶交付，时间极度紧张

使用方式：只采纳 Claude Code 建议中的“单列索引”，手动复核所有“复合索引”。

时间紧的时候，你的精力是瓶颈。把最容易判断的单列索引交给 Claude Code 处理（准确率约 85%-90%），把需要综合判断的复合索引留给自己。

一个经验数字：如果你只有 30 分钟审核时间，花 5 分钟验证所有单列索引的 EXPLAIN，花 20 分钟逐一分析每个复合索引的列顺序和必要性，最后花 5 分钟跑一遍 pt-duplicate-key-checker。不要把时间平均分配给每一条建议。

策略 D：新项目，表结构和查询模式尚未定型

使用方式：不要用 Claude Code 建索引。

新项目早期，查询模式每周都在变，表结构两个月内可能重构。这个阶段建索引的收益极低，你今天建的索引，下个迭代可能因为代码重构而失效，但写入成本会一直存在。

我的建议是：在查询模式稳定下来之前（通常是最少上线 3 个月后），只建那些“不建会导致全表扫描并且查询频率较高”的基础索引。 Claude Code 在这个阶段的作用是帮你快速识别“哪些查询是全表扫描”，而不是设计索引。

十一、三个你可能会犯的认知偏差

在结束之前，我补充三个在“AI + 数据库”这个交叉领域里，我观察到的最常见的认知偏差。这些偏差不是 Claude Code 的问题，而是我们自己使用时的心理陷阱。

偏差一：自动化偏误

这是经典的“自动化偏误”，当一个自动化系统输出结果时，人类倾向于降低自己的警觉性，默认结果正确。具体到 Claude Code 的场景：它给出的索引建议，语法完全正确，格式规范，还附带了“解释为什么这个索引能优化查询”的说明文本。这种高度自信的输出格式，会让接收者不自觉地跳过了“这真的是正确的吗”这一步。

应对方法：对每一条 Claude Code 的建议，强制自己用红色字体在文档里写一行“这个索引是否存在被优化器忽略的可能？”作为提醒。

偏差二：确认偏误

你心里已经知道“这张表的order_status缺了索引”，然后你问 Claude Code“这张表哪些字段需要建索引”，它告诉你“order_status需要建”。你立刻采纳，因为你和它观点一致。但如果它同时建议了另一个你不认可的索引，你可能会忽略或质疑。

这就是确认偏误：我们倾向于接受能印证自己已有观点的人工智能输出，而拒绝与自己直觉冲突的部分。 在 Claude Code 的索引建议中，它给出的 6 条建议里可能有 3 条是对的、3 条是错的。如果你只采纳验证了自己直觉的 3 条而忽略另外 3 条，那你既没有从 Claude Code 那里获得新价值，又可能漏掉了它正确而你没意识到的问题。

应对方法：让 Claude Code 按“你认为最重要的索引”和“你认为最可选的索引”分类，然后强制自己对“最可选”的类别花同等时间验证。

偏差三：成本沉没偏误

当你花了一个小时用 Claude Code 调试生成的迁移脚本，反复修改提示词直到它给出了一个看起来很完善的方案时，你会产生“这个方案值得被采纳”的感觉，因为你投入了时间。

但时间投入和质量产出之间没有因果关系。 Claude Code 在第 10 次尝试时给出的建议，并不比第 1 次给出的更可靠。它只是在你的反复调整下更好地“匹配了你的期望格式”，而非“更好地理解了数据库优化”。

应对方法：不看迭代次数，只看每条建议在 EXPLAIN 里的实际表现。一个 30 秒生成的建议，如果 EXPLAIN 验证通过，比一个调了 20 轮生成的建议更值得采纳。

十二、结论：把它当“提示器”，用它但不信它

回到标题的那个问题：Claude Code 辅助编写数据库迁移脚本时对索引建立的建议是否可靠？

我的答案是：在你能用三步验证（EXPLAIN + pt-duplicate-key-checker + 写入负载测试）覆盖的范围内，可靠度中等偏上；超出这个范围，可靠度断崖式下降。 它的价值不是“替你决策”，而是“帮你想起你可能会漏掉的东西”，就像副驾驶能帮你看到后视镜盲区里的车，但方向盘必须握在你手里。

我在订单表翻车之后，给自己立了一条现在还在遵守的法则：

所有 Claude Code 生成的索引建议，默认状态下是“待验证假设”，不是“技术决定”。 从“待验证”到“执行”，中间必须经过那五步审核，没有例外、没有捷径、没有“这次看起来简单就不用了吧”。

如果你能接受这个定位，Claude Code 会成为你在数据库迁移中效率最高的助手之一。如果你希望它是你的“自动化 DBA”，那你会失望，甚至可能制造出比你手动建索引更糟糕的结果。

最后想说的是：Claude Code 的建议质量下限其实不低，它不会建议你建索引在随机字段上，不会漏掉明显的全表扫描，不会犯低级语法错误。 真正危险的不是它的建议有多“错”，而是它的建议看起来太“对”，对到让你放弃了二次确认。

而数据库生产环境的容错率是零。一次错误的索引决策，代价可能是凌晨两点的生产事故和整个周末的复盘。当你面对一份 Claude Code 生成的迁移脚本时，最值得回顾的不是它有多聪明，而是你对“信任”二字的边界定义得有多清晰。

下一步行动清单：

如果你正在或即将使用 Claude Code 辅助数据库迁移，请在下次拿到它的索引建议时，做这三件事：

1. 立刻跑一次 EXPLAIN，把输出截图保存，和 Claude Code 的建议并列对比
2. 在代码仓库里新建一个 db-review 目录，把每条索引建议的审核记录（包含 EXPLAIN 结果、pt-duplicate-key-checker 输出、写入负载测试数据）整理成 Markdown，纳入 Git 版本控制
3. 在团队文档里加入“AI 生成数据库迁移脚本审核规则”，参照本文第五部分的五步审核法，让每个提交迁移脚本的开发者都能遵循同一套标准

数据库不会原谅任何一个不被审核的假设。这句话，我写在团队 Wiki 的数据库变更规范第一行。现在，送给你。