程序員最幸運的一次投資: 一次學會，可用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 寫得像不像，人類必須判斷性能和正確性。