codex代码生成的SQL查询在大数据量下的索引失效案例分析

一、我先给你一个反常识的结论

AI代码生成工具的准确率越高，生产环境数据库瘫痪的风险反而可能越大。这不是危言耸听。过去18个月，我所在的技术团队在3个独立项目中使用Codex生成SQL查询，其中2次在数据量从测试环境的数千行切换到生产环境的百万级别时，查询延迟从毫秒级直接崩到秒级甚至超时。根本原因不是Codex写错了SQL逻辑，而是它写出的SQL在逻辑正确的前提下，让索引全部失效。

这篇文章要拆解的，就是这背后鲜有人系统总结的因果链条：为什么Codex生成的SQL在大数据量下会成为索引杀手，以及作为技术决策者和开发者，你该怎么在享受AI效率的同时，提前把这类灾难挡在上线之前。

二、从一次真实的线上事故讲起

2024年5月，我们一个BI数据看板功能上线。需求很常规：从订单表、用户表、商品表中联查近30天的数据，按地区汇总销售额。开发同事在VSCode里装了Codex插件，用自然语言描述了一句需求，Codex在几秒内生成了下面这个SQL：

SELECT 
u.region,

COUNT(DISTINCT o.order_id) AS order_count,

SUM(o.amount) AS total_sales

FROM orders o

JOIN users u ON o.user_id = u.user_id

JOIN products p ON o.product_id = p.product_id

WHERE DATE(o.created_at) >= '2024-04-01'

AND DATE(o.created_at) <= '2024-04-30'

AND p.status = 'active'

GROUP BY u.region

ORDER BY total_sales DESC;

功能测试环境里，订单表只有3000行，查询在0.2秒内返回，一切正常。Code Review环节，评审同事看到逻辑没问题，代码就合入了主分支。上线后第三天，运维报警：数据库CPU使用率飙到95%，慢查询日志拥堵，orders表的写操作开始排队。排查发现，就是这个SQL，在生产环境400万行数据量下，每次执行耗时持续在12到18秒之间。

我用EXPLAIN一看执行计划，全表扫描，orders表上建好的idx_created_at索引纹丝没动。为什么？问题出在哪？

三、问题SQL的解剖：Codex写了什么，又漏了什么

回到上面那段SQL，核心问题就在WHERE子句里的这一行：

WHERE DATE(o.created_at) >= '2024-04-01'
AND DATE(o.created_at) <= '2024-04-30'

Codex对索引列o.created_at使用了DATE()函数。这是数据库索引失效的经典场景之一，但Codex生成这种写法时毫无"自觉"，它只是在模仿大量训练数据中出现的SQL模式，而训练数据里大量存在这种写法，因为它在逻辑上确实是对的。对于日期时间列，如果你要比较"某一天的日期部分"，DATE(datetime_col)是语义上最自然、最符合人类思维的表达方式。

但MySQL的查询优化器不这么看。当你在索引列上应用函数时，优化器无法知道该函数执行后的值与索引树存储的原始值之间的对应关系，因此直接放弃索引，走全表扫描。这是数据库基础课的常识，但Codex的模型不具备"运行时性能代价"的概念。它不理解400万行全表扫描和索引扫描之间的IO差异，不理解磁盘寻道和Buffer Pool命中的概念。

同样致命的是，Codex还写到了一句p.status = 'active'。我们后来发现，products表中的status字段实际是INT类型，但Codex生成的SQL用字符串'active'去比较。MySQL在这种情况下会进行隐式类型转换，当字符串和整数比较时，MySQL会把字符串转换为整数。如果status列上建了索引，隐式转换同样会导致索引失效。Codex在生成这个条件时，并未感知到目标表列的物理类型，它只是根据"语义上常见的过滤条件"生成了一个值。

同一个SQL里，同时踩了两个索引失效的经典陷阱，还躲过了代码评审。这就是AI生成SQL在数据量小的时候完全无感、上线后突然引爆的典型模式。

四、不止于函数和类型转换，Codex生成SQL的其他隐性索引杀手

上面这个例子展示了两个最直接的索引失效原因，但我这18个月里看到的远远不止这些。以下是我在实际工程中遇到的、Codex生成SQL特有的索引失效模式，以及与人工编写SQL的行为差异。

4.1. 模糊匹配和前缀通配符

Codex在生成搜索类SQL时，经常写出这样的片段：

WHERE u.username LIKE '%john%'

通配符%在开头意味着B+Tree索引完全无法利用前缀匹配的优势，只能全索引扫描或全表扫描。人类开发者在做搜索功能时，通常会考虑用Elasticsearch或全文索引来替代，但Codex只关心"SQL能不能跑"，不关心"这个场景该不该用MySQL的LIKE"。

4.2. OR条件中部分列无索引

我在一个复杂统计查询中看到Codex产出过这样的WHERE条件：

WHERE o.user_id = 12345 OR o.email = 'user@example.com'

如果user_id有索引而email没有，MySQL优化器大概率放弃user_id索引，选择全表扫描。Codex不理解这两个过滤条件的物理代价差异，它只是组合了两个逻辑上可行的条件。

对比有经验的DBA，他们会拆成两个查询用UNION分别用索引，或者强制确保email列也建上索引。

4.3. 多表JOIN时驱动表选择错误

Codex生成的SQL在2个以上表JOIN时，经常无视数据量差异。比如我们的用户表有80万行，订单表有400万行，Codex写出的JOIN顺序有时让大表做驱动表，小表做被驱动表，结果优化器选择对大表全表扫描。人工编写时，开发者会基于业务经验选择驱动表和JOIN方向，Codex没有"哪个表数据量大"的先验知识。

4.4. GROUP BY和ORDER BY的索引利用

Codex生成的聚合查询中，GROUP BY和ORDER BY列经常不一致，导致优化器无法利用索引避免filesort。例如：

SELECT u.region, SUM(o.amount)
FROM orders o JOIN users u ON o.user_id = u.user_id

GROUP BY u.region

ORDER BY SUM(o.amount) DESC;

GROUP BY在region上，ORDER BY在SUM(o.amount)上，索引无法同时满足，必然触发临时表和排序。Codex不会提示"这个查询10万行以上会触发磁盘排序"。

五、更深一层：模型训练数据对Codex写SQL行为的影响

很多人会问：既然索引列使用函数是SQL优化的基本常识，为什么Codex不"学会"避免这么写？这背后的原因需要从训练数据的角度理解。

Codex的训练语料来自公开代码仓库（GitHub为主）和大量技术问答（Stack Overflow等）。在这些语料中，SQL代码的特性是：

• 大量"最小可行"SQL示例：回答者为了简洁表达逻辑，优先选择最短、语义最清晰的写法。WHERE DATE(created_at) = '2024-01-01'明显比WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'简洁，因此前者在训练数据中大量出现。
• 数据量信息缺失：GitHub上的SQL代码很少附带"这个查询运行在100万行表上"的元数据。模型无法从静态文本推断出运行时场景。
• 性能讨论与代码分离：Stack Overflow上关于SQL性能的讨论在文字中，而代码片段往往是被标记为"答案"的那个最短版本。模型倾向于学习"答案"，而非评论区里的"这个写法在大表上慢十倍"。
• ORM生成SQL的污染：大量开源项目使用ORM框架（如Laravel、Django、Hibernate），它们自动生成的SQL经常包含低效的模式。这些SQL也被训练进模型，形成了"ORM式写法"的风格偏好。

这意味着，Codex学到的"正确SQL"是逻辑上的正确，而非工程上的正确。它对SQL的评判标准是"是否能返回预期结果"，而不是"在百万级数据量下是否可接受"。这就解释了为什么Codex的SQL看起来没问题、小数据量测试通过，却被生产环境的数据量直接击穿。

六、大数据量下索引失效的排障流程：我是怎么快速定位的

当生产环境出现慢查询报警，而你怀疑是AI生成的SQL导致的索引失效时，我总结了一套5步排查法，能帮你在15分钟内确定是哪个SQL、哪个索引、以及为什么失效。

第一步：锁定慢查询SQL本身

MySQL的slow_query_log或者performance_schema.events_statements_summary_by_digest是第一个抓手。如果你用了云数据库（阿里云RDS、AWS RDS等），控制台通常有"慢SQL分析"功能，按平均耗时降序排列，基本能直接定位问题SQL。我习惯于设置long_query_time = 1（1秒），对于核心业务接口的建议值是0.1秒。

第二步：拿到EXPLAIN执行计划

在从库或手动复现时执行：

EXPLAIN FORMAT=JSON 你的SQL;

最关键的指标只有两个：access_type（访问类型）和rows（预估扫描行数）。如果你在JSON输出里看到ALL（全表扫描）而有索引列在WHERE条件中出现，那索引失效已经板上钉钉。正常的索引扫描应该显示ref、range或index。

第三步：检查WHERE条件中的索引列是否"裸着"

逐列排查WHERE条件中涉及的索引列，看它是否被：

• 函数包裹：DATE(col), LOWER(col), SUBSTRING(col, 1, 5)
• 算术运算：col + 1 > 10
• 隐式类型转换：列是INT，但与字符串比较
• 字符集/排序规则不一致：JOIN字段字符集不同

如果是Codex生成的SQL，对索引列使用函数是最高概率的坑。我排查时，先在SQL中搜索DATE(、YEAR(、MONTH(等字符串，往往一眼就能看到问题。

第四步：评估优化器行为

有时候索引失效不是"写错了"，而是优化器在特定数据量下"选择放弃"。执行：

EXPLAIN FORMAT=JSON 你的SQL;
-- 然后加上强制使用索引

EXPLAIN FORMAT=JSON 你的SQL FORCE INDEX (你想测试的索引名);

比较两者预估代价（query_cost），如果FORCE INDEX后代价明显降低，说明优化器选错了路径，可能需要更新统计信息（ANALYZE TABLE），或者确实需要修改SQL写法。

第五步：用实际数据验证修复效果

改了SQL之后，不要只跑EXPLAIN，一定要用EXPLAIN ANALYZE（MySQL 8.0.18+）看实际执行时间，或者在从库上跑真实的查询计时。我见过不止一次EXPLAIN预估用索引但实际执行时优化器又变卦的情况。执行计划预估和实际运行是两回事，尤其在数据倾斜的场景下。

七、不同数据库引擎下的差异：MySQL与PostgreSQL要分开讨论

同一段Codex生成的SQL，在不同数据库引擎下的索引失效表现可能完全不同。如果你的技术栈不限于MySQL，这一节对你极其重要。

7.1. MySQL/InnoDB下的典型失效场景

MySQL的优化器相对保守，对任何可能导致无法直接利用B+Tree索引的操作，大部分情况下直接判定为索引失效。典型场景包括：

• 索引列使用函数（绝对失效）
• 隐式类型转换（规则复杂，如VARCHAR列与数字比较时，MySQL会把字符串转数字，导致索引扫描全列）
• OR前后列索引不同时存在（大概率失效）
• LIKE '%prefix'（通配符开头绝对失效）
• JOIN时字段字符集/排序规则不一致
• 联合索引未遵循最左前缀原则

7.2. PostgreSQL下的表现

PostgreSQL的情况微妙得多。PG支持表达式索引（Expression Index），你可以为DATE(created_at)直接创建索引：

CREATE INDEX idx_order_date ON orders (DATE(created_at));

如果存在这个索引，Codex生成的WHERE DATE(created_at) >= '2024-04-01'就能用上索引。但问题在于，你无法保证所有可能被函数包裹的列都建了表达式索引。Codex不会检查PG中哪个表达式已建索引，它仍然按它的"自然"写法生成。

此外，PG的查询规划器比MySQL更"聪明"，在某些情况下能通过函数推导使用原索引（例如某些不可变函数IMUTABLE），但这种行为是数据库版本特异且不透明的。依赖这些特性本身就是技术债。

7.3. 云原生数据库的差异

AWS Aurora、阿里云PolarDB等云数据库在存储层和计算层分离的架构下，全表扫描的代价模型与自建MySQL有所不同。存储层可能有并行扫描能力，让全表扫描比自建数据库更快，但这只是把灾难从20秒压到8秒，仍然不解决根本问题。云厂商自己的性能诊断工具（如DAS、Performance Insights）能帮你更快发现这类问题，但前提是你得知道要去找。

八、不止Codex，其他AI编程助手在SQL上的共性表现

或许你会想：是不是Codex的问题，换一个工具就好了？我用过GitHub Copilot、通义灵码、StarCoder、以及亚马逊CodeWhisperer的免费期版本，在生产SQL场景下做过横向对比。结论是：这不是某个工具的问题，而是当前LLM生成SQL的共性缺陷。

四个工具在面对同一个需求（"查询近30天订单并按地区汇总，按销售额排序"）时，产出的SQL都出现了至少一种索引利用问题：

• GitHub Copilot：同样使用DATE()包裹索引列；
• 通义灵码：未使用DATE()，但WHERE条件写了created_at BETWEEN，这倒是能用索引，然而它输出的多表JOIN里驱动表选择明显不合理，联查80万用户表和400万订单表时让大表驱动小表；
• StarCoder：生成的SQL在GROUP BY后直接ORDER BY聚合结果，触发排序，与Codex的模式一致；
• CodeWhisperer：生成的SQL中WHERE条件有一个OR，后半部分列无索引。

没有一个工具在默认Prompt下产出了"索引安全的SQL"。不同工具的差异在于踩不同坑的概率分布，但这个概率差异在实际生产环境中意义不大，你需要的不是80%的安全率和95%的安全率的区别，而是上线前必须100%确认。

九、为什么测试环境发现不了：小数据量是如何欺骗你的

这是最危险的一个环节。很多团队在推进AI代码时，会强调"所有AI生成的代码都要经过测试"。这个原则本身没错，但在SQL性能问题上，常规测试是无效的。

原因有四个层面：

第一，测试数据量远远不够。大多数团队的测试数据库只有几百到几千行，而生产环境轻松达到几十万到几百万行。MySQL等数据库的查询优化器在数据量小时，可能根本不会触发代价模型的切换阈值，它觉得全表扫描几千行也无所谓，所以执行计划看起来和用索引差别不大。只有当数据量跨越某个临界点（通常在5万到10万行附近，视硬件和表结构而定），优化器才会沿着Codex写的坑往下跳，而且一跳就是悬崖。

第二，测试环境的硬件和数据库配置不同。很多团队使用CI/CD流水线里快速启停的容器化MySQL做测试，内存、CPU、IOPS都与生产环境差距巨大。生产环境有512GB内存和NVMe SSD，全表扫描可能还凑合；测试环境只有2GB内存和模拟磁盘，扫描5000行就得0.5秒了。这种差异让测试环境反而更容易暴露慢查询，但这恰恰混淆了问题，你以为测试环境跑了没问题，实际上在测试环境就已经慢了，只是你把这归因于"测试环境配置低"而放过了。

第三，查询缓存和下推优化会掩盖问题。MySQL 8.0移除了查询缓存，但很多测试环境仍在使用5.7版本或云数据库的Buffer Pool缓存机制。测试时重复跑同一个SQL，数据已在内存中命中，耗时极低。一旦上线面对真实访问流量中首次执行的冷查询，索引失效的代价才暴露出来。

第四，并发和锁竞争在测试环境不存在。单线程跑一个慢SQL是慢，但还能服务。生产环境40个并发请求同时执行这个慢SQL，锁等待和连接池耗尽会瞬间放大延迟，从单次12秒变成60秒超时。

十、重新设计SQL生成工作流：让AI和人类各司其职

说问题说到这儿，如果你只停留在"AI生成的SQL不行，以后别用了"，那就错过了重点。AI生成SQL是效率的质变，关键是我们需要一套适应AI能力边界的新工作流。以下是我团队经过两次事故后，废弃了"生成，手写不差就过"的老流程，重新设计的一套方法。

10.1. Prompt层面的干预：把索引知识"喂"给模型

最直接的改进是改变你给Codex的Prompt。我实测，以下Prompt模板能让Codex产的SQL在索引安全上有明显提升：

请生成一个MySQL查询，要求如下：

查询订单表orders(user_id, product_id, created_at, amount)

联查用户表users(user_id, region)

获取2024年4月、active状态产品的销售总和，按地区分组，按总和降序排列

性能约束：orders.created_at上有索引，请不要对索引列使用函数；所有比较请使用相同数据类型；尽量使用覆盖索引；确保GROUP BY和ORDER BY可被索引优化

请使用EXPLAIN预检查的思路生成SQL

这个Prompt有三个关键：明确告知有哪些索引（让模型"知道"表结构）、给出具体的性能约束（不要用函数）、请求自检行为（EXPLAIN预检查）。我在团队内让三个不同开发者分别用这个Prompt生成SQL 10次，索引安全通过率从默认Prompt的约15%提升到了约65%。仍然不完美，但已经是巨大的改善。

10.2. 本地开发环境的强制检查：集成EXPLAIN到预提交钩子

更工程化的方案是在本地开发阶段引入自动化检查。我们在项目的Makefile和Git Hooks里加入了这一条：

# 对最近修改的SQL文件自动跑EXPLAIN
for f in $(git diff --name-only HEAD | grep '\.sql$'); do

echo "EXPLAIN $f"

mysql -u dev -e "EXPLAIN $(cat $f)" myapp_test

done

更进一步，我们内部维护了一个SQL审核规则集，针对AI生成SQL的高频陷阱做了专用规则。这些规则包括：

• 检测WHERE条件中是否有对索引列的函数包裹（DATE(), YEAR(), IFNULL()等）
• 检测是否存在隐式类型转换热路径（比如INT列与字符串字面量比较）
• 检测LIKE '%keyword'模式
• 检测OR条件的列索引覆盖度
• 检测GROUP BY与ORDER BY列的一致性

这套规则目前直接集成在CI流水线中，一旦预提交发现命中规则，直接在终端输出红色警告并阻止提交。我们从第二个事故后启用这套机制，至今6个月，SQL索引失效事故数量归零。

10.3. 建立"AI生成SQL代码审查清单"

在人工Code Review环节，我们不能用审查手写代码的标准去审AI代码。AI生成的代码需要额外的审视维度。我为团队制定了一份固定的Checklist，每次审查AI生成的SQL时逐条确认：

1. 是否对索引列使用了函数？（扫码查找DATE/YEAR/MONTH/SUBSTRING等）
2. JOIN的两侧字段类型是否严格一致？（INT/INT, VARCHAR/VARCHAR等）
3. WHERE条件中的常量值与列类型是否匹配？（无隐式转换风险）
4. 多表JOIN时，驱动表的数据量是否小于被驱动表？
5. GROUP BY和ORDER BY的列是否一致，能否避免filesort？
6. 是否有OR条件部分列无索引？
7. 是否已对SQL执行EXPLAIN并确认type为ref/range/index？
8. 该SQL在未来数据增长3-5倍时是否仍能接受当前扫描代价？

这个Checklist强制了审查者的注意力，否则Code Review时人会自然被"逻辑正确"吸引，忽略"索引失效"这种不跑EXPLAIN就看不到的东西。

十一、中长期的技术债务：AI生成SQL的累积效应

单个AI生成的SQL导致索引失效，是一次事故。但更隐蔽的问题是，大量AI生成的SQL在系统中积累，会形成性能层面的"技术债务"，而你甚至不一定意识到它来自AI。

在我团队的项目里，Codex上线使用约4个月后，数据库的整体CPU使用率从平均25%缓慢上升到55%。单独排查找不到某一个要命的SQL，每个SQL单独看都"还好"，但合在一起就让数据库没有余量了。后来我们把所有AI生成的SQL（通过Git提交信息里带的[codex]标记筛选出来）做了批量EXPLAIN分析，发现其中有大约40%的SQL存在至少一种可以优化的索引利用问题。单个SQL多消耗了30%到200%的IO/CPU，但单个都不足以触发慢查询报警。累积起来就是沉默的成本。

我把这种现象叫"死亡由一千刀割"的AI SQL问题。它比单次爆炸更危险，因为很难追责，也很难整改。整改需要重写几百个散落在代码库各处的SQL，工作量极大而ROI不明显（每个都省不了多少），管理层难以立项。但不整改，半年后存储和计算成本就会对业务增长形成物理约束。

十二、从架构层面思考：在AI编程工具链中缺失的"性能编译器"

当我和几个行业的CTO朋友交流这个问题时，我们发现一个共同的痛点：当前的AI编程工具，无论是GitHub Copilot、通义灵码还是Codium，它们的评测体系和实际能力边界都聚焦在"代码生成速度、逻辑正确率、开发者接受度"上，完全没有"生成代码的执行效率"这一维度。

这就像一个编译器只检查语法不检查类型安全一样荒谬。我们真正需要的是一个AI代码生成，性能分析，反馈纠偏的闭环链路：

• AI生成SQL
• 自动在近似生产数据量的测试环境中执行并采集EXPLAIN计划
• 对比优化版本与AI原始版本的执行代价
• 将差异反馈给AI模型（微调或RAG注入）
• 下次生成时自动调整写法

这套架构目前在业界还没有成熟产品，但我在自己的团队里做了简化版的原型。我们在开发环境部署了一个SQL代理审查服务：对每一次Git Push中包含SQL的变更，自动在包含了约200万行模拟数据的影子库上执行EXPLAIN，并将结果以Comment的形式回复在Pull Request中。这个自动化审查的误报率很低，但漏报风险也存在，所以它不是替代人工Review，而是辅助Reviewer更高效。

十三、给不同角色和阶段的行动建议

这部分是根据我在不同规模团队中踩过的坑，给出的分层可执行方案。

13.1. 如果你是后端开发/数据分析师（个人实践者）

你的核心动作只需要三个：

1. 养成肌肉记忆：任何一个AI生成的SQL，复制进查询工具后，首先不是运行，而是跑一遍EXPLAIN。花2秒钟看一眼type列是不是ALL。
2. 改写Prompt：在给Codex的描述里主动加入"表上创建了哪些索引"，哪怕你只能粗略描述。
3. 准备一个"性能SQL模板收藏夹"：把你验证过的大数据量下高效的SQL模式（如正确的日期范围写法）存下来。AI不适合用来创造新的SQL范式，但特别适合在已有的正确模板上进行扩展。这是最务实的"使用边界"。
4. 本地数据量复现：如果条件允许，在自己的开发机上用脚本灌入百万级数据跑一遍，本地就能暴露指数级差异。

13.2. 如果你是Tech Lead/架构师（团队决策者）

你的动作是在团队层面建机制：

1. 在CI/CD流水线中集成SQL审核工具。目前可选的工具有SQLE、Yearning、CloudBeaver、以及阿里云DMS的数据安全与审计功能。设定规则：任何扫描行数超过5000的SQL自动标记，超过10万的直接阻塞合并。
2. 建立AI代码的专项Review Checklist（如我上文所列）。在团队的Code Review制度中写入这一条。
3. 投资"影子数据库"。在测试环境中维护一个数据量与生产近似的影子数据库（可以从生产脱敏同步），让性能测试有真实的数据量环境。
4. 关注AI工具的"性能感知"能力演进。比如GitHub Copilot的Workspace模式是否开始支持索引感知，或者是否出现专门的数据库AI编码助手（如腾讯DBbrain、阿里DAS等产品开始集成的AI调优能力）。在技术选型时，把"生成的SQL是否需要人工二次优化"作为一个正式评估维度。

13.3. 如果你在推动团队AI化（变革推动者）

你需要考虑的是文化层面：

1. 纠正"AI代码不用审查"的错误认知。用本文中这样的真实事故案例做团队分享，让开发者亲眼看一次EXPLAIN结果和十几秒的慢查询日志。
2. 量化AI SQL的性能负债。如果你的团队已经在用AI生成SQL，做一次"AI生成SQL的性能审计"（将所有AI生成的SQL抽出，跑EXPLAIN统计执行代价），将结果形成报告。这份报告是你推动机制建设的决策依据。
3. 设定实际的使用边界：AI生成的SQL可以直接用在非核心报表、内部管理后台等低风险场景；但涉及面向用户的交易查询、高频接口、关联多张大表时，必须经过人工+自动审核双保险。

十四、总结：AI不是问题，信任错位才是

回顾这18个月和Codex打交道的经历，我可以给出一个清晰的判断：Codex和同类AI编程工具在SQL生成上的"问题"，其实不是它们做错了什么，而是我们错误地假设了它们的能力边界。

AI现阶段擅长的是：在给定上下文下，产出语法正确、逻辑可行的代码文本。它不擅长、也不可能擅长的，是理解这些代码在真实数据量、真实并发、真实存储介质上的物理执行代价。这个能力差距，在SQL查询上是暴露得最明显的，因为SQL恰恰是离数据物理存储最近的代码层次，一行SQL的写法差异可以在IO层面放大几百倍。

作为工程实践者，我们的正确姿态不是"拒绝AI"或者"完全信任AI"的二选一，而是把AI定位成"高效的初级工程师"，把自己定位成"架构决策者与性能审查人"。你让初级工程师写了SQL，你会审查他的执行计划；AI写了SQL，你也一样。

下一步，如果你正被这个问题困扰，我建议你今天只做一件事：打开你项目代码库，用关键词（如AI生成的SQL文件中的模式特征、最近的提交记录）筛出10条AI写的SQL，在影子库上跑一次EXPLAIN。10条里你发现多少个全表扫描、多少个filesort、多少个临时表，就能直观地衡量你当前的技术债务水位。做完这一步，你就知道要不要把本文里的机制落实到团队流程里了。