2026，1月1日元旦當(dāng)天，中國銀行APP故障：

故障原因，先有消息說因?yàn)檫B接池滿、無法與數(shù)據(jù)庫建立新的連接導(dǎo)致。

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

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

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

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

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

分析每家故障的原因，試途尋找“中行APP故障原因”、“工行APP故障原因“，“支付寶雙11/雙12故障原因”，就像分析“這個家庭為什么不幸福”、“那個家庭為什么不幸福”一樣沒有意義，因?yàn)椤安恍业募彝ジ饔懈鞯牟恍摇薄?/p>

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

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

因?yàn)閿?shù)據(jù)庫不強(qiáng)，不得不把更多的壓力轉(zhuǎn)移到上層（應(yīng)用層），導(dǎo)致應(yīng)用層架構(gòu)復(fù)雜，出現(xiàn)問題的概率，大大增加。

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

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

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

但關(guān)鍵就是，我們的技術(shù)方向錯了。

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

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

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

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

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

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

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

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

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

(1 row)

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

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

步1：使用perf，打開CPU ”指令數(shù)“計數(shù)器，針對進(jìn)程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)計結(jié)果更精準(zhǔn)。

步2：到后臺進(jìn)程24636對應(yīng)的Session中，執(zhí)行目標(biāo)SQL：

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

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

我不是要說高斯基不基礎(chǔ)、強(qiáng)不強(qiáng)嗎？跑題了嗎？

并沒有。

單看一個指令數(shù)，確實(shí)沒啥意義，但橫向?qū)Ρ榷鄠€數(shù)據(jù)庫，就有意思了。

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

在高斯中，目標(biāo)表大小為196MB：

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

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

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

步1：得到線程標(biāo)識：47503107229440

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

步3：把線程標(biāo)識47503107229440，轉(zhuǎn)為16進(jìn)制：0x2b342dd50700

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

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

繼續(xù)步5。

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

步6：在線程25416對應(yīng)的gsql Session中執(zhí)行目標(biāo)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倍多。

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

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

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

為什么是這樣？

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

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

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

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

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