程序员最幸运的一次投资: 一次学会，可用30年

如果让程序员们投票选举：“过去50年最成功的软件抽象是什么？”

我觉得前三名大概率是：

1.TCP/IP

2.Unix & C

3.SQL

SQL能位列3甲，是因为它完成了一件几乎不可能的事：几十年来，硬件、软件、框架、类库换了一波又一波，开发方式从单机，到局域网，到互联网，再到移动互联网，云计算，但是SQL一直没变。

你随便翻开一本1995年出版的数据库教材，找到类似的查询：

ORDER BY headcount DESC;

把它粘贴到 2026 年的 PostgreSQL 18 中，它依然可以运行。

同样的语法，同样的结果，同样的思维模式。

三十一年了，没有任何变化，实在是太惊人了。

相比而言，假设你有一个 2015 年的 React 组件，它使用了 React.createClass 、mixins 和 componentWillMount 。它不仅看起来老旧，而且一加载就会抛出 TypeError: React.createClass is not a function ，你现在需要从头开始重写它才能发布。

当然，SQL的发展也不是一帆风顺的，今天我们来聊聊它的历史。

0 1

SQL 诞生

大家都知道，关系数据库是IBM的研究员科德提出来的，但是SQL却不是他发明的。

科德提出了关系模型，这个模型在数学上非常漂亮。

一个关系（“表”），无论你做什么操作，选择也好，投影也好，连接也好，它的结果还是一个“表”，实在是优雅。

但是，数学的完备并不意味着好用，关系代数的符号就让人头皮发麻：

选择 ：Selection（σ）

投影 ：Projection（π）

并集 ：Union（∪）

笛卡尔积 ：Cartesian Product（×）

这些运算符号在键盘上都敲不出来。

所以，当两个新人张伯伦和博伊斯进入IBM，开始实现关系数据库System R的时候，他们立刻就注意到了这个问题。

两人把复杂的关系代数，改成了非专业人士都能理解的英语：

WHERE e.manager = m.name and e.salary > m.salary

这个新语言叫SEQUEL，意思是Structured English Query Language，翻译过来就是“结构化英语查询语言”。

不巧的是，SEQUEL已经被一家英国公司注册成商标了，两人一拍脑门：换个名儿吧！于是就有了更简单、更好记的SQL。

那个时候，IBM还没打算把SEQUEL真正做成产品，就由着他们把论文拿到一个技术会议上发表。

谁去宣读呢？两人干脆用抛硬币来决定。最后博伊斯赢了，由他上台。

可谁也没想到，会议结束刚过一个月，博伊斯就因为脑瘤去世了，才27岁。真是天妒英才。

0 2

竞争对手

痛失挚友后，张伯伦没有停下脚步，他决定完成博伊斯未竟的事业。

他被任命为System R的技术经理，在System R里真正把SQL做了出来，同时还想证明一件事：关系数据库到底能不能搞定商业里那些复杂的事务处理。

就在差不多的时候，UC Berkeley也在做类似的事情。

他们开发了一个叫Ingres的关系数据库，目标一样，但路子不一样——他们专门设计了一套自己的查询语言，叫QUEL。

delete s where s.name="liuxin"

时间一晃到了80年代，计算机价格一路往下掉，终于跌到了一个临界点：很多公司都买得起计算机和软件了，纷纷想把纸质的表格塞进电脑里存储。

数据库的需求一下子就爆了。因为“表”这东西特别好理解，基于关系数据库写程序也变得简单起来。

System R和Ingres都挺成功，但问题来了——SQL和QUEL，到底谁能笑到最后？

0 3

Oracle 立功

这时候，在科德所在的那个城市圣何塞，一个叫Larry的年轻人出手了，一下打破了天平。

Larry看到了科德的论文，也看到了SQL的论文，他被震撼了：关系数据库，绝对是未来。

他二话不说，拉上两个朋友，成立了一家小公司，他自己掏了1200美元，朋友凑了800美元，开始基于VAX小型机搞关系数据库。

深受张伯伦和博伊斯论文影响的他，自然选择了SQL。

1979年，Oracle正式问世。Larry靠着自己的人脉，开始向美国海军、CIA这些部门推销。

他到处吹牛：“我们的数据库不需要IBM的大型机就能跑，价格便宜，还用上了最先进的SQL！”

更骚的是，Oracle 当时发布的第一个版本直接叫：Version 2，没有 Version 1。

为什么这么干？

因为客户觉得Version 1 肯定有Bug，于是 Larry Ellison 干脆跳过 Version 1，直接卖 Version 2。

结果客户一看：哟，都迭代到第二版了，成熟，可以买。

这个骚操作后来成了软件史上的经典案例。

Oracle 在美国政府中的应用非常成功，以至于美国政府发布了一个联邦信息处理标准，指定在联邦数据库中要使用SQL，而不是别的查询语言！

得到官方认证的SQL击败了QUEL，成为了最终的胜利者。

很快，SQL被ANSI, ISO等重磅机构采纳为正式标准。

没想吧，现在恶名累累的Oracle居然对SQL的普及做过重大的贡献。

0 4

回归王位

关系数据和SQL在八九十年代横扫市场，占据了主流。

时间很快来到2010年，Web 2.0火得一塌糊涂。

用户生成内容（UGC）爆炸，社交关系，Feed流，动态墙......这些东西和传统表格不一样：一个用户的资料里可能有地址、兴趣、好友列表，结构不但经常变，还带嵌套，每个人可能都不一样。

如果用传统的关系型数据库，得设计好多张表，还要考虑怎么连（JOIN），改个字段甚至要停机。

所以JSON格式开始流行了。

}

前端用JSON，API返回JSON，大家自然会有一个问题：为什么数据库不是JSON？

自然而然，像MongoDB这样的文档数据库就开始兴起了。

关系数据库受到了重大打击，支持文档数据库的阵营甚至起了个名：NoSQL。

意思是不要SQL！

NoSQL 运动是 SQL 所面临的最严峻挑战，MongoDB、 CouchDB 、DynamoDB 和 Cassandra 都押注文档型数据库和键值数据库将取代关系型数据库模型。

在那几年时间，“直接用 MongoDB”几乎成了 Stack Overflow 上很多问题的答案。

但是很快大家就发现，文档数据库并不能“取代 SQL”。

因为缺乏模式（表结构）、数据完整性约束很弱、对事务的支持很弱，甚至干脆没有， 这引起了程序员的强烈不满和抗议，慢慢地，SQL又回来了。

Snowflake，以 SQL 为核心。

BigQuery，以 SQL 为入口。

Databricks，把 SQL 做成了一等公民。

连 Spark，也专门做出了 Spark SQL。

甚至很多 NoSQL 数据库最后都偷偷加上了 SQL 查询层。

SQL 没死，反而把敌人同化了。

0 5

AI喜欢SQL

最近两年有个很有意思的现象，大模型写Java、C++、Python时容易出错，偶尔胡编，但是写SQL往往表现很好。

这可能有两个原因：

1.SQL是声明性语言，告诉模型 “做什么”（What）

例如：SELECT name FROM users WHERE age > 18

模型只需要理解：目标=取name，条件=age>18，来源=users表。

这是一个小范围、映射关系明确的任务。数据关系清晰（表、列、行），逻辑相对线性。

Java/C++（命令式/过程式）：告诉模型 “怎么做”（How），还要考虑状态、副作用、异常处理、内存管理……

2.SQL的“语法空间”和“语义空间”非常小

SQL的关键字只有几十个，语法规则相对固定。模型要生成的“符号”种类有限。

对比Java：有上千个标准库类、成百上千的方法、复杂的泛型和并发模型。模型犯错的空间极大。

既然AI能把SQL写好，那我们还需要去学习SQL吗？

答案是肯定的，因为AI虽然擅长写语句，但是人类必须理解语义，“销售额”是订单创建时间还是支付时间？是否排除退款？是否按税前金额计算？

这些决定结果对不对，而不是 SQL 写得像不像，人类必须判断性能和正确性。