SQL 代码审查中的 AI：能否取代资深 DBA 的审查？

人工智能正在迅速进入软件开发生命周期的几乎每个阶段。从代码生成到自动测试，AI 工具正越来越多地嵌入开发人员的日常工作流程中。最近的开发者调查显示，84% 的开发人员已经在使用或计划使用 AI 工具进行开发，其中超过一半的开发人员经常依赖它们。

许多工程团队现在正在问的一个问题很简单：如果 AI 可以生成代码、分析模式和建议优化，是否也可以取代一位资深 DBA 的判断力?

答案很简单：不能。但更有趣的现实是，AI 正在改变 SQL 代码审查的方式。与其取代数据库专家，AI 正在开始重塑围绕他们的开发工作流程。

传统的 DBA 代码审查角色

长期以来，SQL 代码审查一直依赖于经验丰富的 DBA。SQL 的一个特点是，它不独立运行。每个查询都与数据库引擎、索引和实时数据相交互。因此，即使是小的查询更改也可能影响其运行方式。

有时，这些小的更改比你想象的更重要。一个糟糕的查询可能会导致全表扫描、选择错误的索引，并且突然整个系统都会变慢。

这就是为什么 DBA 以不同的方式看待 SQL。他们不仅仅是在阅读查询；他们正在思考数据库在实际流量下的行为。在审查过程中，DBA 通常会检查以下内容：

• 低效的连接或深度嵌套的查询。
• 缺失或误用的索引。
• 可能触发全表扫描的查询。
• 可能阻塞其他事务的锁定风险。
• 可能影响生产工作负载的操作。

但这种审查的真正价值不仅仅在于了解 SQL 语法。它在于了解查询背后的系统。

经验丰富的 DBA 通常了解模式如何随时间演化、流量在高峰时段如何表现以及对索引的小更改如何影响执行计划。在纸面上看起来完美的查询可能在面对实际生产数据时表现出很大的不同。

从事大型系统工作的工程师经常讨论这个问题。正如 Google 工程师 Jeff Dean 所指出的，系统在大规模运行时不会按照我们的预期行为。

正如 John Gall 所说，“一个复杂的系统可以以无数种方式失败。”

这些想法共同表明，为什么大型系统需要谨慎的人类监督。即使 AI介入，经验丰富的 DBA 仍然至关重要。他们不仅仅阅读查询；他们预测整个数据库系统将如何响应。

但随着对经验的需求如此之高，你可能会想，“AI 是否可以帮助这些审查，或者甚至改变它们的方式？”

软件开发中 AI 的崛起

过去几年中，AI 开始改变开发人员编写软件的方式。曾经感觉实验性的东西现在正成为日常工作的一部分。

训练有素的语言模型可以分析大量代码库，并像第二个开发人员一样在编辑器中工作。它们建议函数、帮助编写文档，并有时在代码编写过程中指出错误。像 GitHub Copilot 这样的工具已经迅速融入了许多开发工作流程中。

这种转变已经开始显示出可衡量的影响。一些研究发现，使用 AI 助手的开发人员可以在受控环境中比正常情况下快 55% 完成编码任务。随着团队采用这些工具，AI 正在开始影响编写的代码量。一些估计表明，大约 40% 的现代工作流程中的代码现在涉及某种形式的 AI 协助。

大型科技公司也正在看到同样的模式。微软 CEO 萨蒂亚·纳德拉最近表示，大约 30% 的微软代码现在是使用 AI 工具编写的，而且这个数字正在不断增长。

然而，生成代码只是拼图的一部分。随着 AI 帮助产生更多代码，审查代码的方式变得更加重要。

AI 可以改进 SQL 代码审查的地方

这就是 AI 开始显示其真正价值的地方。SQL 有一种对 AI 有利的模式：大多数查询遵循可识别的结构，许多性能问题以可预测的方式出现。由于此原因，训练有素的 AI 系统可以快速扫描查询并检测开发人员在早期开发过程中可能遗漏的问题。

例如，AI 助手可能会指出以下内容：

• 低效的连接模式。
• 缺失或误用的索引。
• 可能触发全表扫描的查询。
• 潜在的性能瓶颈。
• 可能不安全运行的操作。

这些检查不能取代完整的审查。但它们可以捕获到开发人员在早期开发过程中可能忽略的大量问题。并且这改变了 SQL 开发的方式。开发人员不必等待后续的代码审查，而是在编写查询时就能获得反馈。这种早期的反馈循环可以节省大量时间。一些关于 AI 辅助开发的研究发现，一旦引入自动分析，审查周期可以显著减少。一个企业研究报告了大约 31.8% 的拉取请求审查时间减少。

在实践中，这意味着许多 SQL 问题在进入生产系统之前就被捕获了。这也是现代 SQL 开发工具开始演变的地方。例如，dbForge 生态系统中的工具现在包括 AI 辅助的查询分析，可以建议更好的连接、发现不必要的索引，并在编写查询时提供查询结构的提示。它有助于尽早捕获问题。

但是，如果我们放大视野，AI 仍然存在局限性。

AI 在数据库工程中的局限性

尽管取得了令人印象深刻的进步，AI 仍然难以应对数据库工程中最具挑战性的部分：上下文。SQL 查询很少独立运行。其性能取决于系统中的许多因素，包括：

• 数据分布
• 表大小
• 现有索引
• 并发工作负载
• 硬件约束
• 业务特定逻辑

训练有素的 AI 模型通常缺乏对这些现实的可见性。更令人担忧的是，AI 生成的代码可能会引入微妙的错误。最近的一项分析发现，高达 45% 的 AI 生成的代码样本包含安全漏洞，突出了在没有人类审查的情况下依赖自动化建议的风险。信任也是一个挑战。虽然采用率正在迅速增长，但调查显示 46% 的开发人员仍然不完全信任 AI 生成的输出，从而在自动化和监督之间产生了自然的紧张关系。在数据库工程中，这种怀疑是有道理的。一个在开发环境中运行完美的查询可能在面对生产工作负载时表现出很大的不同。

混合模型：AI + 人类专业知识

最有效的开发团队不再问是否 AI 会取代 DBA。相反，他们正在问如何将 AI 自动化与人类专业知识相结合。使用这种模型，AI 工具处理正常减慢开发速度的重复检查，而经验丰富的工程师则专注于需要更深入判断的数据库工作部分。例如，AI 系统可以处理以下任务：

• 检测语法错误
• 建议查询改进
• 标记低效的查询模式
• 运行自动分析检查

这些检查可以在开发人员编写查询时立即进行，这有助于尽早捕获许多问题。同时，AI 处理这些常规检查，DBA 专注于需要更深入系统理解的工作：模式设计、索引策略、性能优化、容量规划和保护生产稳定性。

换句话说，AI专注于加速SQL开发的常规部分，而DBA专注于决定数据库系统实际行为的决定。

最后的话

AI已经开始改变SQL开发的方式。工具可以分析查询、捕获常见错误并在开发人员编写代码时突出潜在的性能问题。但是，数据库系统不仅仅由查询语法决定。模式设计、索引策略和工作负载行为仍然需要人类的判断力。因此，最有效的团队开始将AI视为协同工具，而不是替代品。

AI可以提前标记问题、加快开发速度，但开发人员可以更快地迭代，而DBA可以专注于决定数据库实际行为的更深入的决定。这种平衡之处才是真正的价值所在。AI带来了速度和模式识别。经验丰富的DBA带来了上下文和判断力。在数据库工程中，正是这种组合使系统保持快速、可靠和稳定。