AI写SQL快得离谱，几秒钟就能把一段看似合理的查询甩到你面前。结果也对，跑起来也没报错。然后它进了生产，每天被调用上千万次，CPU曲线开始抬头，I/O延迟悄悄爬升，你才意识到问题不在功能，在性能。
结果正确只是及格线
几十年来，缺乏经验的开发者一直犯同一个错：只看查询有没有返回想要的行。返回了，就收工，下一个任务。DBA看到这种操作只会叹气，因为返回正确结果和写出好SQL之间隔着一条河。
这条河里有几个关键问题：为了拿到那几行，引擎实际扫了多少行？有没有走索引，走的哪个？有没有多余的排序？谓词能不能被索引利用？连接策略合不合理？有没有不小心搞出笛卡尔积？表从十万行涨到一亿行，这条SQL还能不能扛住？
AI生成的SQL经常踩这些坑。它会把查询写得过分复杂，在已建索引的列上套函数直接把索引废掉，生成冗余子查询，或者明明有现成索引却不用。这些问题在开发阶段根本看不出来，因为测试库太小了。
乘数效应才是真正的杀手
应用代码低效，一天跑一次，顶多让人烦。SQL低效，一天跑一千万次，就是运营事故。
假设AI生成的某条查询每次多消耗几毫秒CPU。开发阶段没人会注意到，测试库小、响应快、功能测试全绿。但把这几毫秒乘以数百万次执行，它就开始吃CPU、拉高I/O、干扰其他工作负载，账单也跟着涨。在Db2 for z/OS这类高吞吐事务系统上尤其致命，微小的低效在海量负载下会被放大到难以承受。
问题不在于SQL是AI写的。人类写烂SQL的历史和SQL本身一样长。区别在于速度。AI让开发者生成代码的速度远超以往，如果审查和验证SQL的能力跟不上这个速度，技术债只会积累得更快。
性能测试必须左移
过去数据库性能分析通常在部署之后才做。应用上线，响应变慢，CPU飙高，用户投诉，然后才有人找DBA。这套流程本来就不高效，在AI辅助开发的时代更撑不住。
SQL分析应该嵌进开发生命周期，而不是等应用上线后再补。开发者在写代码和测试的过程中就该收到问题SQL的反馈。部署之前就要审查访问路径、索引需求、谓词构造、估算成本、基数、排序、连接方式这些性能特征。越早发现低效SQL，修复成本越低。
这里有个容易被忽略的验证手段：在测试环境用真实数据量级做执行计划对比。拿生产库的统计信息导入测试库，对同一条SQL分别跑EXPLAIN，看访问路径是否一致。如果测试环境走了索引而生产环境预期会走全表扫描，说明统计信息或数据分布有偏差，这条SQL上线就是定时炸弹。判定标准很简单：估算行数与实际行数偏差超过一个数量级，就必须人工介入。
自动化防护网怎么搭
用AI编码助手的企业，除了应用层的防护机制，还得建数据库层的防护机制。自动化SQL分析应该成为CI/CD管道的一部分。
具体做法是制定标准，自动标记潜在问题SQL。触发标记的条件包括：大规模表扫描、笛卡尔连接、可疑谓词、过多排序、异常高的估算成本、违反既定SQL编码规范。标记出来交给人审查，而不是直接阻断。
目的是让AI加速开发的同时，有一套能同步跟上的自动化控制措施。自动化分析不会取代DBA，反而让DBA更有价值，把精力集中在异常处理、架构决策、工作负载交互和棘手性能问题上，而不是逐条手工检查。
一个容易踩的坑：索引不是越多越好
AI有时候会建议加索引来优化某条查询。听起来合理，但加索引这件事有代价。每个额外索引都会拖慢插入和更新性能，占用存储，增加维护开销。优化单条SQL不等于优化整个系统。
这里有个实际场景值得注意：在MySQL 8.0中，不可见索引（invisible index）可以用来做安全验证。你可以先把新索引设为不可见，观察一段时间确认它对整体工作负载没有负面影响，再正式启用。命令是ALTER TABLE tbl_name ALTER INDEX idx_name INVISIBLE; 验证完再改成VISIBLE。这个特性从MySQL 8.0开始支持，5.7及更早版本没有。如果你还在用旧版本，加索引前只能靠人工评估或者影子库测试。
另一个版本差异：PostgreSQL从12版本开始对CTE的物化行为做了改变，默认不再自动物化CTE，除非你显式写MATERIALIZED。AI生成的SQL如果大量使用WITH子句，在PG 12之前和之后的行为可能完全不同，执行计划会变，性能特征也会变。审查时得确认目标数据库版本。
谁来做最终判断
有人预测AI和自动化会减少对DBA的需求。实际情况可能相反。AI辅助开发恰恰证明了人类数据库专业知识的不可替代性。
总得有人分得清能跑的SQL和可扩展的SQL。总得有人理解工作负载全貌。总得有人知道加索引帮了一条查询却可能拖垮写入。总得有人明白优化单条语句和优化整个系统是两回事。这些判断需要大局观、经验和取舍能力，目前只有人能提供。
氛围编程确实能大幅提升开发效率。但开发提速而工程规范没跟上，只会让问题更快冲进生产环境。
让开发者用AI生成代码，让AI建议SQL，让开发加速。但在那条SQL进入高吞吐生产库之前，得有人——或者更理想的是，有人支持的自动化流程——问出那个老问题：它能跑，但跑得怎么样？
ID:6512
