2026，1月1日元旦當天，中國銀行APP故障：

故障原因，先有消息說因為連接池滿、無法與數(shù)據(jù)庫建立新的連接導致。

但進一步暴漏的信息，這里的“連接池”是數(shù)據(jù)庫內(nèi)的線程池BUG，導致上層應用無法和數(shù)據(jù)庫建立連接，問題直指GaussDB。

現(xiàn)場曾重啟數(shù)據(jù)庫、華為的相關人員也介入解決問題，但故障依久，最終故障持續(xù)了超過1個小時，才恢復正常。

我對故障具體細節(jié)并不關心，去年（2025年）金融行業(yè)IT基礎設施問題頻發(fā)，四大行有兩家都未能幸免（工行與中行），支付寶更是在2024雙11后，又于2025雙12出問題。細看每一次故障原因各不相同，每一次故障也都有獨自的特點。

托爾斯泰在《安娜.卡烈林娜》中有一句流傳很廣的名言：“幸福的家庭千篇一律，不幸的家庭各有各的不幸”。

對應技術層面：“不宕的系統(tǒng)一直運行，宕機的系統(tǒng)各有宕機的原因”。

分析每家故障的原因，試途尋找“中行APP故障原因”、“工行APP故障原因“，“支付寶雙11/雙12故障原因”，就像分析“這個家庭為什么不幸?！?、“那個家庭為什么不幸福”一樣沒有意義，因為“不幸的家庭各有各的不幸”。

不如提高視角，問一個共性的問題：“為什么現(xiàn)在會有這么多故障”？“我們走錯了方向嗎”？

這個問題太宏大，我還要聚焦焦，只討論現(xiàn)代商業(yè)管理系統(tǒng)吧。我在這篇中，用最直白的話解釋過了，這么多故障的根因，就是數(shù)據(jù)庫不強。

因為數(shù)據(jù)庫不強，不得不把更多的壓力轉移到上層（應用層），導致應用層架構復雜，出現(xiàn)問題的概率，大大增加。

而且復雜的架構，導致高可用切換行同虛設，事到臨頭時，無法確保數(shù)據(jù)一致的切換，導致每次故障時間都是以“小時”為單位。

從底層硬件、操作系統(tǒng)，到數(shù)據(jù)庫，再到中間件、上層應用系統(tǒng)，這一整套現(xiàn)代商業(yè)管理系統(tǒng)，是美帝摸索了幾十年探索出來的技術路線。

單說數(shù)據(jù)庫，從上世紀七零年代做為一門獨立的軟件門類開始，到現(xiàn)在發(fā)展已逾50多年，美帝在這方面有著深厚的積累，華為又不是上帝，數(shù)據(jù)庫又只是華為的支線業(yè)務，比不上美帝本不足為奇。只要我們的技術方向不錯，追平美西方就不是問題。

但關鍵就是，我們的技術方向錯了。

這么頻繁的故障頻率，四大中兩家不足三個月內(nèi)，接連出問題；

中小銀行我都懶的說，故障時間都以“天”為單位了；

支付寶在敏感時間點接連出問題，要是還覺得一切OK，就當我啥也不懂吧。

我們在用開發(fā)應用層軟件的方法，開發(fā)基礎軟件。先不要急著反駁我，下面我證明給你看，中行與工行的數(shù)據(jù)庫、華為高斯，到底基不基礎、強不強。

先說一個問題：“誰最有資格評價一個數(shù)據(jù)庫強與弱”。

不是你也不是我，而是處理器 --- CPU。

數(shù)據(jù)庫也是程序，數(shù)據(jù)庫并不是跑在空氣中，而是運行在CPU之上。對CPU而言，任何程序不過是一段段代碼，數(shù)據(jù)庫也是，它并不例外、并不特殊。

CPU有豐富的手段衡量一段代碼的好壞，我們先用一個最簡單的例子，牛刀小試一把。我以一條極簡單的SQL為例，統(tǒng)計它所用的指令數(shù)量。

先以PG為例，先介紹一下基本環(huán)境：目標表vage2，大小206MB，共有4列，ID列為主鍵。當前后臺進程為24636。

(1 row)

上面是顯示一些基本信息。

按如下步驟，可以得到執(zhí)行某SQL時所使用的CPU指令數(shù)：

步1：使用perf，打開CPU ”指令數(shù)“計數(shù)器，針對進程24636，統(tǒng)計它執(zhí)行的指令數(shù)：

是不是沒想到，CPU內(nèi)計數(shù)器，說起來很玄乎的概念，打開它竟十分的簡單，一條perf命令就可以了。

"instructions:u"中的“:u”，是只統(tǒng)計用戶態(tài)執(zhí)行的指令數(shù)。我們排除于內(nèi)核態(tài)的指令，去除一些干擾，統(tǒng)計結果更精準。

步2：到后臺進程24636對應的Session中，執(zhí)行目標SQL：

步3：回到“步1”的perf命令窗口，Ctrl+C，就能看到結果了：

105,649，就是“步2”的SQL所用指令數(shù)。一條極簡SQL，使用了10萬多條CPU指令。CPU只需不足一秒，就能跑出結果?，F(xiàn)代處理器，還是很強悍的。

我不是要說高斯基不基礎、強不強嗎？跑題了嗎？

并沒有。

單看一個指令數(shù)，確實沒啥意義，但橫向對比多個數(shù)據(jù)庫，就有意思了。

下面看看同樣的表、同樣的SQL，在華為高斯數(shù)據(jù)庫中，使用了多少條CPU指令。

在高斯中，目標表大小為196MB：

和在PG中基本相同（PG中是206MB）。

列數(shù)量（4列）、行數(shù)（300萬行）完全相同，連插入的數(shù)據(jù)都完全一樣。

高斯是線程模式，先要得到后臺線程號，步驟如下：

步1：得到線程標識：47503107229440

步2：在gdb中調(diào)試高斯的進程：

步3：把線程標識47503107229440，轉為16進制：0x2b342dd50700

再使用"i thr"，列出所有線程

步4：搜索0x2b342dd50700，就能得到線程號：25416

繼續(xù)步5。

步5：使用perf，打開CPU ”指令數(shù)“計數(shù)器，這次針對線程25416，統(tǒng)計它執(zhí)行的指令數(shù)：

步6：在線程25416對應的gsql Session中執(zhí)行目標SQL：

步7：回到perf，Ctrl+C：

在高斯中，執(zhí)行和PG同樣的SQL，使用了989,183條指令。

還記得PG使用了多少條指令嗎，105,649條。高斯是PG的9.36倍。

數(shù)據(jù)量相同、列相同、連數(shù)據(jù)都一模一樣，執(zhí)行相同的SQL，高斯使用的指令數(shù)是PG的9倍多。

這意味著什么，表達同樣的意思、說同樣的話，PG使用了1萬個字，高斯使用9萬多個字。高斯使用的字數(shù)，是PG的9倍多。

說句不好聽的話，我聽到我兒子幼兒園同學們的談話，費話極多、還有大量的重復、邏輯略微混亂，能用一個字說清的，可能用了9個字才說清楚。有時候用了9個字也沒有說清楚。

華為高斯和幼兒園小朋友不同是，高斯用9個字，把話說清楚了。

為什么是這樣？

我這里使用的技術極簡單，僅用一條perf命令，只觀察了一個計數(shù)器的結果：指令數(shù)。高斯的表現(xiàn)就已經(jīng)這樣了，還需要從L1~L3 Cache、TLB、iCache、前端吞吐、譯碼效率、ROB/RS/LB/SB使用情況、流水線STALL比例、……，等等方面完整分析嗎。（上面這些分析我計劃后面開一個系列好好講講）

CPU中的計數(shù)器可是多達近千個的，可以對程序進行全方面的profilling。

我想表達的意思是：基礎軟件開發(fā)有自己的知識體系，從處理器層對程序進行profilling，也僅是其中的一環(huán)。從現(xiàn)實的表現(xiàn)看，華為高斯團隊并不掌握基礎軟件開發(fā)的知識體系。

但高斯仍是一個典型的工程實現(xiàn)很棒的應用層軟件。

我是說，高斯是一個應用軟件，工程質(zhì)量很棒。但高斯并不是一個基礎軟件。原因是走錯了方向，在按應用層軟件的思路，開發(fā)基礎軟件。