遥遥领先的华为数据库故障，导致中国银行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，也仅是其中的一环。从现实的表现看，华为高斯团队并不掌握基础软件开发的知识体系。

但高斯仍是一个典型的工程实现很棒的应用层软件。

我是说，高斯是一个应用软件，工程质量很棒。但高斯并不是一个基础软件。原因是走错了方向，在按应用层软件的思路，开发基础软件。