遙遙領先的華為數據庫故障，導致中國銀行app中斷服務

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

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

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

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

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

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

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

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

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

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

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

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

從底層硬件、操作系統，到數據庫，再到中間件、上層應用系統，這一整套現代商業管理系統，是美帝摸索了幾十年探索出來的技術路線。

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

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

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

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

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

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

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

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

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

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

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

(1 row)

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

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

步1：使用perf，打開CPU ”指令數“計數器，針對進程24636，統計它執行的指令數：

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

"instructions:u"中的“:u”，是只統計用戶態執行的指令數。我們排除于內核態的指令，去除一些干擾，統計結果更精準。

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

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

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

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

并沒有。

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

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

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

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

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

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

步1：得到線程標識：47503107229440

步2：在gdb中調試高斯的進程：

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

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

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

繼續步5。

步5：使用perf，打開CPU ”指令數“計數器，這次針對線程25416，統計它執行的指令數：

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

步7：回到perf，Ctrl+C：

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

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

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

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

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

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

為什么是這樣？

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

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

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

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

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