“氛围编程”是应用开发领域近期广为流传的一个新词。其基本理念相当简单：开发人员无需费力地手动编写每一行代码，而是向AI编程助手描述需求，审查其生成的代码，进行调整，然后继续推进。开发过程因此变得更具对话性、更具迭代性，而且至少在理论上，效率也更高。

“氛围编程”确实有很多值得称道之处。但在从“帮我构建一个能实现这个功能的应用程序”到将该应用程序部署到生产环境的过程中，存在一个数据库专业人员应格外关注的问题：SQL。

AI能够快速生成SQL。它生成的SQL通常能得出正确的结果。但正如每位经验丰富的DBA所知，返回正确结果的SQL并不一定就是好的SQL。

而“勉强够用”的SQL一旦投入生产环境，其代价可能会非常高昂。

功能正确不等于高效

AI生成的SQL所面临的一个根本性问题，正是我们几十年来在应对缺乏经验的开发人员时所面临的问题：人们往往只关注是否得到了正确的结果。我们会检查查询是否返回了所需的行，如果返回了，那就很好。

接着就转到下一个任务。没错，我们确实需要确保结果正确，但DBA们深知还有更多工作要做。为了返回这些行，系统共扫描了多少行?是否使用了索引(如果有，是哪些)?是否存在不必要的表扫描?查询中是否引入了排序操作?谓词是否可索引?连接操作是否高效?是否无意中引入了笛卡尔积?当表从10万行增长到1亿行时会发生什么?

AI生成的SQL语句看似完全合理，却可能暗藏细微的性能问题。编码助手可能会构建不必要的复杂查询，在已建索引的列上使用阻碍高效访问的函数，生成冗余的子查询，或者未能充分利用现有的索引。

在规模扩大之前，SQL运行良好。

乘数效应

这正是数据库工程与单纯生成应用程序代码的显著区别所在。一段低效的应用程序逻辑如果每天只执行一次，可能只是令人烦恼;但一条低效的SQL语句如果每天执行1000万次，则会演变成运营噩梦。

假设一条由AI生成的查询仅额外消耗了几毫秒的CPU时间。在开发阶段，没人会注意到这一点。

测试数据库规模较小，响应时间看起来没问题，应用程序也通过了功能测试。

现在，将这些毫秒数乘以数百万次的执行次数。突然间，那条看似无害的SQL语句开始消耗大量CPU资源，增加I/O负载，干扰其他工作负载，并可能导致基础设施或软件成本上升。对于Db2 for z/OS这样的高吞吐量事务处理系统而言，这一点尤为重要——微小的低效在海量工作负载中累积，最终可能造成极其高昂的代价。

问题并不在于SQL是由AI生成的。自SQL诞生以来，人类就一直在编写低质量的SQL语句。区别在于速度。AI使开发人员能够比以往任何时候都更快地生成代码(包括SQL)。如果我们审查和验证SQL的能力无法以同样的速度提升，我们只会更快地积累技术债务。

不要等到投入生产环境再行动

过去，数据库性能分析往往要等到部署完成后才进行。应用程序投入生产环境后，响应时间变慢，CPU占用率上升，用户开始抱怨，这时才有人联系DBA。

这种模式原本就不够高效。在人工智能辅助开发的时代，这种做法变得越来越难以维系。数据库性能测试需要“左移”。

SQL分析应作为开发生命周期的一部分，而非在应用程序投入生产之后才进行。开发人员应在编写和测试应用程序的过程中，就要收到关于存在问题的SQL的反馈。这意味着在部署之前，就需要审查访问路径、索引要求、谓词构造、估计成本、基数、排序、连接以及其他性能特征。因为越早发现低效的SQL，修正的成本就越低。

AI生成SQL的防护措施

采用AI编码助手的企业应在其应用程序开发防护机制之外，同步建立数据库防护机制。自动化SQL分析应成为CI/CD管道的一部分。

企业可以制定标准，自动标记潜在问题SQL。例如，当查询执行大规模表扫描、包含笛卡尔连接、使用可疑谓词、产生过多排序、显示出意外高的估计成本，或违反既定的SQL编码标准时，系统应将其标记为待审查。

其目的并非阻止开发人员使用AI，而是利用AI加速开发进程，同时配合能够与之同步的自动化控制措施。

请记住，自动化分析并不会取代DBA。它反而能提升DBA的价值，让经验丰富的数据库专业人员能够专注于处理异常情况、架构问题、工作负载交互以及棘手的性能问题，而非手动检查每一条语句。

AI需要数据库工程

多年来，有人预测自动化和AI将减少对DBA的需求。但事实上，AI辅助开发或许恰恰能证明，为何由人类主导的数据库专业知识仍然不可或缺。

仍然需要有人理解“能运行的SQL”与“可扩展的SQL”之间的区别，需要有人理解工作负载。需要有人意识到，在某些情况下，添加索引虽然有助于某个查询，却会损害整体插入和更新性能。

而且，必须有人明白，优化单个SQL语句并不一定等同于优化整个系统。这些决策需要具备大局观、判断力和经验的人来做出。而这个“人”就是DBA。

氛围编程可以极大地提高开发人员的生产力。但如果开发速度加快却缺乏相应的工程规范，只会让问题更快地进入生产环境。

因此，尽管让开发人员随心所欲地编写代码吧，让AI生成代码，让它建议SQL语句，让它加速开发。但在该SQL语句进入高吞吐量的生产数据库之前，请确保有人(或者更理想的是，由某人支持的自动化流程)——即了解数据库工程的人——提出那个始终至关重要的问题：它能运行，但它的性能如何?

作者：Craig S. Mullins