存储引擎的结构决定了数据库的一些基本特性，数据库的功能实现与存储引擎关系密切。我以前也多次撰文讲到没有完美的存储引擎，某种类型的 存储引擎必然在某些领域有优势，但是在其他方面存在缺点。LSM-TREE存储引擎前些年十分热，大家都认为这种新型的存储引擎将会成为未来的主流。OceanBase、TiDB、Yuga等数据库都采用了LSM-TREEE存储引擎。在高并发写入和简单的定位查询方面，LSM-TREE表现不俗，但是这些年也暴露出来在7*24的关键业务系统中，合并带来的负面影响，这个影响比基于HEAP 的ASTORE(比如PG)的Vacuum影响还要大。有得必有失。BTREE存储引擎天然有打散热数据的能力，但是维护BTREE的成本以及一致性读产生的IO放大问题要比普通的 HEAP存储引擎要大不少。当然有些学术文章吧BTREE看成是HEAP的一个子类型。不过我们的分类还是把它们分为两类。在普通情况下二者差别确实不大，不过要实现类似Oracle RAC的功能，二者的差别就更大了。

其实 存储引擎涉及的细节很多 ，不是简单从分类就能给某个数据库排排座次的，我以前在几本书里都分析过O记的存储引擎，包括块结构，行结构。O记的行锁与存储引擎的完美结合，真的可以称为艺术品。前阵子和一个在做RAC的国产数据库厂商的研发人员聊天的时候，他也感叹这一点。他觉得虽然他们处处学习Oracle，但是没有行内的锁标志位，让他们在实现RAC上遇到了很多性能问题。

目前主流国产数据库除了在传统行式存储引擎的基础上进行了优化改造，大部分都进一步地提供了列式存储引擎，有些还提供了内存引擎。下表是我梳理的一些国产数据库 的存储引擎方面的特征，可能有些不够准确的地方，如果大家发现了，请帮我纠正一下。