元旦当天华为高斯数据库BUG 直接搞摊中国银行APP

寂静回声

原作者4号的文章经大伙传播后，华为高斯数据库当即投诉原作者侵犯名誉。
但投拆被驳回。
气急败坏的华为高斯数据库心生一计，又以违返《网络安全法》、泄露国家秘密为由，再次投诉。
那么，问题来了，原作者泄露的是什么国家秘密？是华为高斯数据库只有幼儿园水平？还是中行APP故障？
中行APP元旦故障，都他娘快上热搜了，这算秘密？如果这不算秘密，那华为高斯数据库投诉原作者泄露的秘密，就只能是华为高斯数据库只有幼儿园水平了。
下面是原作者4号的原文（略有修改）：
2026，1月1日元旦当天，中国银行APP故障。
故障原因，如今子弹也飞了几天了，我可以百分百确定，就是华为高斯数据库的锅。
托尔斯泰在《安娜.卡烈林娜》中有一句流传很广的名言：“幸福的家庭千篇一律，不幸的家庭各有各的不幸”。
对应技术层面：“不宕的系统一直运行，宕机的系统各有宕机的原因”。
分析每家故障的原因，试途寻找“中行APP故障原因”、“工行APP故障原因“，“支付宝双11/双12故障原因”，就像分析“这个家庭为什么不幸福”、“那个家庭为什么不幸福”一样没有意义，因为“不幸的家庭各有各的不幸”。
不如提高视角，问一个共性的问题：“为什么现在会有这么多故障”？“我们走错了方向吗”？
这个问题太宏大，我还要聚焦焦，只讨论现代商业管理系统吧。我在你的存款还在吗：深度解析工行APP故障到底谁的锅这篇中，用最直白的话解释过了，这么多故障的根因，就是数据库不强。
因为数据库不强，不得不把更多的压力转移到上层（应用层），导致应用层架构复杂，出现问题的概率，大大增加。
而且复杂的架构，导致高可用切换行同虚设，事到临头时，无法确保数据一致的切换，导致每次故障时间都是以“小时”为单位。
从底层硬件、操作系统，到数据库，再到中间件、上层应用系统，这一整套现代商业管理系统，是美帝摸索了几十年探索出来的技术路线。
单说数据库，从上世纪七零年代做为一门独立的软件门类开始，到现在发展已逾50多年，美帝在这方面有着深厚的积累，华为又不是上帝，数据库又只是华为的支线业务，比不上美帝本不足为奇。

但关键就是，我们的技术方向错了。
这么频繁的故障频率，四大中两家不足三个月内，接连出问题；
中小银行我都懒的说，故障时间都以“天”为单位了（猜猜是那个数据库把故障时间干到“天”级了）；
支付宝在敏感时间点接连出问题，要是还觉得一切OK，就当我啥也不懂吧。

我们在用开发应用层软件的方法，开发基础软件。先不要急着反驳我，下面我证明给你看，华为高斯数据库，到底基不基础、强不强。
先说一个问题：“谁最有资格评价一个数据库强与弱”。
不是你也不是我，而是处理器 --- CPU。
数据库也是程序，数据库并不是跑在空气中，而是运行在CPU之上。对CPU而言，任何程序不过是一段段代码，数据库也是，它并不例外、并不特殊。
CPU有丰富的手段衡量一段代码的好坏，我们先用一个最简单的例子，牛刀小试一把。我以一条极简单的SQL为例，统计它所用的指令数量。

先以开源PGSQL为例，先介绍一下基本环境：目标表vage2，大小206MB，共有4列，ID列为主键。当前后台进程为24636。
按如下步骤，可以得到执行某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倍多。

这里使用的技术极简单，仅用一条perf命令，只观察了一个计数器的结果：指令数。华为高斯数据库的表现就已经这样了，还需要从L1~L3 Cache、TLB、iCache、前端吞吐、译码效率、ROB/RS/LB/SB使用情况、流水线STALL比例、……，等等方面完整分析吗。
CPU中的计数器可是多达近千个的，可以对程序进行全方面的profilling。
基础软件开发有自己的知识体系，从处理器层对程序进行profilling，也仅是其中的一环。从现实的表现看，华为高斯数据库团队并不掌握基础软件开发的知识体系。
但华为高斯数据库仍是一个典型的工程实现很棒的应用层软件。
华为高斯数据库是一个应用软件，工程质量很棒。但它并不是一个基础软件。原因是走错了方向，在按应用层软件的思路，开发基础软件。

Architect

基础不牢，地动山摇。