从闩锁操作精简了37行代码说起

白鳝的洞穴 2025-07-24

136

有一年参加一个O记的活动，他们谈到下一个版本的数据库产品的时候，其中有一项十分自豪地宣称，在LATCH的操作中，又精简了37行代码，大大提升了LATCH的访问效率。数据库内核研发有些部分的代码是不断堆砌新需求的，还有一些部分的代码是在不断地精雕细琢的。这些代码的传承延续性很强，在基本框架确定后，需要保持稳定，只能缓慢演进。

就拿Oracle的块结构来说，在Oracle 7之后，Oracle的数据块结构才稳定下来，这个稳定一直持续到现在。实际上Oracle在7之前的块结构是一直在变化的，我记得Oracle 6的数据块中还没有存储data object id，反而存储了这个对象的head块的id，想要校验某个extent中的一个块是否属于某张表，还需要再去读一次Head块。

框架不变不等于这部分代码不再进步，就像上面说的在一个5年的大版本周期里，闩锁的代码又精简了37行。别小看这37行代码，对于每秒钟成百上千万次的闩锁调用来说，节约的可不是一点点。而在O记做这方面开发的工程师是绝对的核心中的核心。

前阵子和一个做国产数据库开发的朋友在线上聊了几句，他说他准备离职了。我问他为什么，他说他不太适应公司的绩效考核机制，所以准备换个东家。我知道他是做SQL引擎开发的，也算是数据库厂商中的核心中的核心这一类人。不知道他的这次跳槽是因为两家的收入差距还是真的像他所说的受不了老东家的绩效考核。如果属于后者，那么我就觉得他的老东家似乎在核心研发管理上存在较大的问题了。

一个企业的研发队伍中，需要做绩效考核的往往是价值最低的边缘研发队伍，他们做的是重复性的劳动，可替代性很强。而核心研发往往是需要研究和探索精神的，需要不断地去试错，不断地探索才能取得进展。如果O记负责闩锁性能优化的小组放在一个对绩效考核很严格的企业里，那么他们的绩效不知道该如何去打了。

作为一个旁观者，我在看国产数据库厂商的时候，有时候确实有些迷茫。在每年的产品发布会上都会推出一大堆又时髦又先进的新功能，在有限的研发人员的条件下，他们是如何做到这一点的？我想国产数据库厂商中目前可能还很少有类似O记闩锁优化小组这样的开发团队存在，他们目前主要还是在不断地开拓新的功能，还没有资源去精雕细琢已经存在的核心功能。

O记已经发展了四十多年，他们也是在10多年后的V7版本中才获得了稳定的块结构，从而在这个稳定的地基上创造了二十多年的辉煌。目前国产数据库才刚刚起步，在他们的第一个十五年里，应该还是在打基础。筑基阶段是十分关键的，需要有大量的有创造性的核心研发人员对关键部分代码进行深度的优化，否则今后会大大限制数据库产品的发展。上周五和Bruce的交流中，又有朋友提到了XID 64，Bruce说为什么XID 64难产，其最主要的问题是PG的行数据中的头部已经太重了，增加一个字节都会对性能产生比较大的影响，因此在这个问题上他们花了太多的时间来权衡利弊，以前的各种方案都会继续增加行头的容量，因此都无法被使用，一个来自俄罗斯的方案可能是可接受的。

我以往在和国产数据库厂商的朋友交流的时候，也有人说：“以前的版本不够成熟，你把我们发的最新版当成1.0吧”。每次发版的时候，都会发现以前的版本在架构上存在严重的缺陷，这是一个刚刚起步的数据库产品应该有的现象。不过我更希望国产数据库厂商能够早日走到ORACLE 7这样的基础稳定的版本，然后把更多的资金投入到打磨产品内核上。对于考核核心研发研发绩效的厂商，我还是有些想不明白，也许是外行在领导内行？

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

从闩锁操作精简了37行代码说起

评论