If all you have is a hammer, everything looks like a nail.

在某个领域做久的人，容易看什么都带着本领域的习惯，数据系统领域的人也不例外。数据库领域推崇以声明式（Declarative）语言取代命令式（Imperative）语言，把简单带给用户，把复杂留给自己。SQL 语言就是前者的典型代表，也获得了巨大的成功。SQL 语言最初实际是简化的英文自然语言，目标想让商业用户也能够方便的查询和处理数据。如果遵循这样的思路来反思，今天的 SQL 语言其实过于复杂，以至于可以说是忘掉了初衷附录 1。在人工智能时代，大模型（LLM）的接口正好是原生的自然语言。用户可以用自己熟悉的某种自然语言（例如母语），甚至混合多种自然语言（和程序语言）来与大模型对话。

那么问题来了。如果大模型的自然语言接口能够取代 SQL，那数据库系统岂不是要寿终正寝了？其实不然，数据库系统擅长处理的是海量数据的精确查询和严格的 ACID（Atomicity、Consistentcy、Isolation、Durability）事务保证；大模型天生擅长处理不那么精确的任务，结果具有随机性（Stochastic），同一个问题问它两遍都可能会给出不同的结果。按照这个思路，正如大模型需要调用计算器等程序来处理准确的计算附录 2，它也应该调用数据库系统来干后者更适合干的事情。我们必须要承认，人类世界要处理的精确任务远没有非精确的任务多；数据库系统擅长处理的结构化数据也远没有非结构化数据多。

既然大模型可以调用其他系统作为工具，为什么不能反过来，这些系统也把大模型当作工具调用？在数据处理领域，确实也有很多类似的做法。很多数据库通过用户自定义函数（UDF）来调用大模型的 API 接口，将表中的数据作为参数传给大模型，做情感分析、文本摘要、图片识别等各种操作；还有一些系统在 SQL 中扩展更多的操作，例如带语义比较的连接（JOIN）；也有一些系统直接在 Python 中仿照 Pandas、SQL 等扩展类似的语义操作。也许我们现在给人类程序员设计的这些语言最终都会变成 AI 来调用。

无论数据库系统与大模型怎么结合，二者之间都存在多种不匹配（也许按照数据库领域的说法，要叫做阻抗不匹配）。首先，语义算子的处理是非精确的，它与传统算子谁先算、谁后算对最终结果会有影响。此外，在怀疑结果出问题的时候，怎么复现和定位分析？其次，相对于传统算子而言，大部分情况下语义算子的处理是很慢的。数据处理任务可能做不到人类期望的交互式响应，而会变成批处理。第三，查询代价估计和查询优化在这种情况下是否还能工作？

附录 1：TPC-DS Benchmark 中的一个查询示例，估计大部分人没法一眼就看懂。

附录 2：Google Gemini 2.5 Pro 用 Live chat 还数不对 Strawberry 中字母 R 的个数