大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
今年上半年，我接了三个新项目的数据库支持。有个现象特别明显------慢查询工单比以前翻了一倍多。查下来，一半以上的问题出在同一个源头：AI写的SQL。
Cursor、GitHub Copilot、通义灵码这些工具普及之后，不会SQL的开发也能直接生成查询语句了。看着是好事，但AI写出来的SQL有一个致命问题------它能写出语法正确的代码，但完全不懂你数据库里到底装了什么样的数据。
上周一个真实案例：某个用AI辅助开发的团队，上线前做压力测试，一条AI生成的关联查询把CPU直接打到98%。查执行计划一看------三张大表做嵌套循环，没有任何索引命中。开发说"AI写的，我看着逻辑没问题就提交了"。
逻辑没问题，但性能崩了。这就是2026年DBA面临的新挑战。
一、AI写SQL的三大致命盲区
盲区一：不知道你的数据长什么样
AI生成SQL时，对你的数据分布、基数、倾斜程度一无所知。它假设数据是均匀的，但现实中的数据从来不是。
举个例子：
sql
-- AI生成的查询，看着完全合理
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.status = 'active'
AND o.created_at > '2025-01-01'
ORDER BY o.total DESC
LIMIT 10;逻辑没毛病。但如果你的users表有500万行，其中status = 'active'的占了90%，而orders表有2000万行，(user_id, created_at)上没有联合索引------这条查询在开发环境的千行测试数据上跑得飞快，到了生产环境就是灾难。
AI不知道status字段的基数几乎等于全表，不知道created_at的选择性有多差，更不知道你的orders表有没有按时间做分区。它只根据语义生成了"看起来对"的SQL。
盲区二：不看执行计划
这是最要命的一点。AI生成SQL后不会帮你跑EXPLAIN，也不会检查是否走了全表扫描。
常见的AI生成SQL性能陷阱：
陷阱一：N+1查询模式
sql
-- AI会帮你把主查询写出来，但不会意识到这需要循环执行
SELECT * FROM orders WHERE user_id = ? -- 然后对每个结果再查一次如果你在代码里对每个订单再查一次用户信息，1000个订单就是1001次查询。AI不会提醒你"这里可以用JOIN"。
陷阱二：隐式转换导致索引失效
sql
-- AI不知道user_id是BIGINT类型
SELECT * FROM users WHERE user_id = '123456'; -- 字符串比较，索引失效类型不匹配导致全表扫描，AI察觉不到，因为你没告诉它schema。
陷阱三：ORDER BY + LIMIT在没有索引的字段上
sql
SELECT * FROM logs ORDER BY created_at DESC LIMIT 10;
-- 如果created_at没有索引，全表排序在百万级数据上，这条查询会触发filesort，把临时表写到磁盘。
盲区三：不考虑并发场景
AI写的SQL在单用户环境下跑得很完美，但没考虑过并发。
sql
-- AI会这样更新状态
UPDATE orders SET status = 'processing'
WHERE status = 'pending' AND created_at < NOW() - INTERVAL 1 HOUR;这条SQL本身没问题。但如果你的系统有50个Worker同时跑这个任务，就会发生锁等待甚至死锁。AI不知道你的并发模型，它只生成了"逻辑正确"的单条语句。
二、为什么这个问题在2026年集中爆发
三个原因叠加：
第一，AI编码工具渗透率陡增。 2026年，Cursor、Copilot、通义灵码等工具已经从尝鲜变成了日常。根据行业调研，超过60%的开发者每周至少使用一次AI辅助编码。但绝大多数人拿到AI生成的SQL就直接提交，不做性能验证。
第二，门槛降低带来的"能力-责任不匹配"。 以前不会SQL的开发会找DBA帮忙，现在直接用AI生成，跳过了DBA这关。代码能跑通就提交，性能问题留到上线后才暴露。
第三，测试环境数据量不足。 开发环境的数据库通常只有几百几千行测试数据，AI生成的慢SQL在小数据量上根本跑不出问题。到了生产环境千万级数据，全表扫描的代价才真正显现。
三、DBA怎么守住底线：SQL审核机制建设
不能让AI写的SQL直接进生产环境。以下是我在实际项目中落地的几道防线：
防线一：SQL提交前必须过EXPLAIN
不管SQL是谁写的（包括AI），提交前必须附带EXPLAIN结果。重点关注：
- type字段 ：不能出现
ALL（全表扫描）或index（全索引扫描） - rows字段：预估扫描行数不能离谱
- Extra字段 ：不能出现
Using filesort或Using temporary
这个规则写进代码审查流程，CI/CD流水线里自动拦截。
防线二：建立SQL规范检查清单
给团队定几条铁律：
- 禁止SELECT * ------AI特别喜欢用
SELECT *，必须改成明确指定字段 - JOIN必须走索引------关联字段必须有索引覆盖
- WHERE条件字段必须有索引或走覆盖索引
- 禁止在大表上做隐式类型转换
- UPDATE/DELETE必须带LIMIT------防止AI生成的条件匹配到全表
防线三：引入自动化SQL审核工具
靠人工审查不现实，特别是团队规模大了之后。需要工具来做自动化拦截。
目前主流的SQL审核方案有几类：
开源方案：Archery、Yearning等开源SQL审核平台，支持SQL语法检查、执行计划分析、变更审批流程。适合有一定运维能力的团队。
商业平台：NineData、CloudDM等企业级数据库管理平台，内置SQL智能审核功能，能自动识别高危SQL、提供优化建议、支持工单审批流程。适合需要规范化管理的中大型企业。
数据库内置能力：部分国产数据库（如金仓KingbaseES）在管理工具KStudio中集成了SQL诊断和优化建议功能，能基于执行历史数据模型主动识别潜在性能问题，在开发阶段就能发现AI生成SQL的隐患。
防线四：AI生成SQL的"使用须知"
给团队里的AI用户定几条规矩：
- AI生成的SQL必须在测试环境跑一遍
EXPLAIN，确认索引命中再提交 - 涉及多表JOIN的SQL，必须让DBA过目
- 批量操作（INSERT/UPDATE/DELETE超过100条）必须走审批流程
- 上线前必须在压测环境用生产级数据量验证
四、给开发者的建议：用好AI但不被AI坑
AI是好工具，但要用对方式：
先告诉AI你的schema。不要只说"查一下用户的订单"，而是把你的表结构、索引情况告诉AI，让它基于你的实际环境生成SQL。
scss
我的表结构：
users(id BIGINT PK, name VARCHAR(50), status TINYINT, INDEX idx_status)
orders(id BIGINT PK, user_id BIGINT, total DECIMAL(10,2), created_at DATETIME, INDEX idx_user_created(user_id, created_at))
请帮我写一个查询，找出2025年活跃的、订单金额最高的10个用户。这样的prompt生成的SQL质量会高得多。
学会看EXPLAIN。不用精通，但至少能看懂type是不是走了索引、rows是不是在合理范围、Extra有没有filesort。
跑不过DBA就跑不过AI。如果你的SQL在测试环境就跑得慢，先自己调，调不动了就找DBA，别直接提交指望生产环境能撑住。
总结
AI写SQL的效率红利是真实的，但它带来的性能债务也是真实的。2026年的DBA需要完成角色转换------从"帮人写SQL"变成"帮人审SQL"。
核心就三件事：
- 建立审核机制------EXPLAIN必过、规范必守、工具必用
- 提升团队意识------AI不是万能，它不懂你的数据
- 把好上线关------压测环境用生产级数据量验证，别让小数据量骗了你
小耶在手，SQL不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~