OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎

AustinDatabases

发布于 2025-03-07 08:44:27

770

Austindatabases公众号已经开启了，AI 文章分析，AI 文章问答，比如你想知道AustinDatabases 里面，说了多少种数据库，那些是讲 MySQL,那些是PostgreSQL, 那些是OB ，POLARDB ，MongoDB ,SQL Server, 阿里云的，问他他会列出来，同时如果有问题不明白，可以将文章的文字粘贴到公众号提供的专用AI ，公众号将通过众多文章（目前1300多篇）来进行尝试性的解释。使用方法，直接到微信公众号中点击服务，选择AI问答。如下示例

一直提到框架学习法，其中主体的思想就是如何快速的学习某项数据库产品的知识。其中框架学习法里面有一条系统学习，系统学习是在给学习的知识搭建“骨架”，所以从这期起，开始搭建OceanBase学习的骨架。今年要和“申公豹”一样修炼岂可怠慢。

这里先解释一下什么是6大学习法，怎么将知识变成一种理念的过程，首先知识的学习是要以兴趣为动力的，没有兴趣去学习是无法提高学习的效率和成效的，在有了兴趣去学习后，那么上来就要上逻辑法，将学习的知识分成小块，也就是我们习以为常的总分总的分，在学习中不断的通过重复记忆，提炼的方法加深记忆，在理解了知识后，使用庞统法，来将知识和周边的常识进行关联，最后通过费曼学习法将知识铁桶话，最后一步就是将学到的知识进行知行合一，这就是将知识转变为自己常识的知识学习6大法。学习OB的兴趣和动力我有了，下面首先就要上的是逻辑法，和重复记忆法。

此篇为OceanBase 视频学习总结的第三篇：这篇主要是围绕OBCA 4.0课程中的第三章进行学习，本章将围绕OceanBase 的SQL 引擎进行学习。

OceanBase SQL 引擎是 OceanBase 数据库的核心组件之一，专用于处理 SQL 查询和数据操作。作为一个第三代原生分布式数据库，OceanBase 的 SQL 引擎具有以下特征：

1 OceanBase SQL数据库引擎兼容了标准的MySQL和Oralce数据库系统的SQL标准的语言。

2 OceanBase的SQL引擎的典型特点在于处理大数据量为基础，高并发和高性能是立足点，支持TP和AP两种业务场景。

3 OB的SQL引擎是一个纯分布式的SQL处理引擎，在满足SQL基本的功能外，要保证分布式架构下的数据强一致性。

4 在我们关注的DDL数据定义语言方面支持在线DDL语句执行的能力。

注解：多租户兼容性，在企业版中的OceanBase支持创建MySQL和Oracle的租户在一个数据库中，提供了兼容MySQL,Oracle数据库完全一致的SQL语法，函数，存储过程和视图等，支持从MySQL或ORACLE 无感的迁移到OceanBase MySQL 租户或 OceanBase Oracle租户。

这里OceanBase数据库引擎中的SQL引擎负责解析SQL语句，并生成执行计划，读取与更新数据由存储引擎完成这里将SQL引擎视为数据库的数据处理的核心。且OB 提供执行几乎HINT的功能，允许用户在SQL语句中指定hint来影响优化器的工作

多租户兼容性。OceanBase 企业版兼容 Oracle 与 MySQL 两种数据库，允许在同一集群内创建兼容 Oracle 和 MySQL 的租户。OceanBase 根据租户的兼容模式，提供与 MySQL 或 Oracle 数据库完全一致的 SQL 语法、函数、系统视图和行为表现。业务可以从 MySQL 或 Oracle 数据库无感地迁移到 OceanBase 的 MySQL 租户或 Oracle 租户。OceanBase 社区版仅支持 MySQL 兼容模式，不支持创建 Oracle 兼容模式的租户。

在OceanBase中时支持数据库对象DDL操作，这里在OB中Database是数据库对象的集合用于权限管理和命名空间的隔离，同时表与普通的数据库相同可以定义主键，非空约束等使用合适的数据类型来对数据进行存储。对于ORACLE中的同义词，存储过程等都有完善的支持。在OB中穿件索引可以指定为局部或全局索引，如LOCAL表示局部索引，而GLOBA老师表示全局索引，不同的数据库模式下，有与同样数据库模型类似的方法查看索引，如SHOW INDEX，get_ddl 等。

在课程中关于库表的介绍信息提供了如下的内容 Database (数据库): 数据库是数据库对象的集合，用于权限管理和命名空间隔离，是一个逻辑概念。在 OceanBase 中，首先需要创建业务使用的租户，然后在租户中创建业务数据所在的 database。

在database里，可以创建多张表，每张表上可以创建不同的索引，在不同的表或者多表之上建立视图等等。

在 OceanBase 的 Oracle 租户中，通过创建 Schema 来创建 database

表 (Table)：表是关系型数据库存储和管理数据的实体，它是二维数据的集合，由纵向的列和横向的行组成。

每一行代表了一个学生的信息数据，每一列代表了学生信息的一个属性，比如学号、姓名、性别、年龄等。一张表有若干列，可以将其中一个或多个列定义为主键。主键可以唯一确定某一行，保证表内任一行的主键值不能重复。在 OceanBase 数据库中所有的表都有主键。

如果在创建表的时候没有指定主键，OceanBase 会默认创建一个自增列作为表的隐藏主键。表的设计常用的一种方法是 ER 模型 (实体关系模型)，ER 模型把现实世界关于数据的概念抽象成实体、属性和关系。实体代表了现实世界中可以区分的一个个对象，映射到数据库中就是表。属性是用来描述实体的，映射到数据库中就是列。关系定义了实体之间的关联及表与表之间的数据的依赖关系，可以使用外键来描述不同表之间的依赖，让数据库来维护多个表之间的引用关系，保证数据的逻辑一致性。

例如，选课表中的学生 ID 必须存在于学生表中。可以在选课表中创建外键，将选课表的学生 ID 与学生表的学生 ID 关联。

SQL 引擎的组成. SQL 引擎负责解析 SQL 语句并生成执行计划，而数据的读取与更新由存储引擎来完成。可以将 SQL 引擎看作数据库的大脑，存储引擎看作数据库的肢体。

执行计划提示。OceanBase 提供了执行计划提示（hint）的能力，允许用户在 SQL 语句中指定 hint 来影响优化器的执行计划选择。通过执行计划缓存避免重复解析 SQL 语句，OceanBase 数据库提供了执行计划缓存功能在首次解析 SQL 语句后，执行计划会被缓存，后续相同的 SQL 语句可以直接复用缓存中的执行计划，从而提高性能。OceanBase 会对 SQL 语句进行快速参数化，将查询条件中的值用参数代替，并生成唯一的 SQLID，以便更好地复用执行计划.

执行计划类型。在 OceanBase 分布式数据库中，SQL 执行计划根据跨节点访问的特征分为三种类型：本地计划、远程计划和分布式计划。

计划缓存管理。OceanBase 提供了计划缓存的刷新机制和自动淘汰机制，以确保执行计划的有效性。用户也可以手动淘汰特定的租户、数据库或 SQL 语句的计划缓存。

在全表扫描索引扫描的部分中介绍了

全表扫描 (Table Full Scan)

定义：全表扫描是指对整张表的所有行进行扫描。

场景：例如，在students表中查找name=Betty的学生，全表扫描需要从第一条记录扫描到最后一条记录。

效率：

如果表的数据量很小，全表扫描的代价不高。

但如果表有大量的记录，比如10万条，那么全表扫描的效率就会很低。

适用性：当查询没有可用的索引，或者优化器认为使用索引的成本高于全表扫描时，数据库会选择全表扫描。

分区表的优化：对于分区表，全表扫描可以在多个节点上并行执行分区级的扫描，提高查询性能。索引扫描 (Table Range Scan)

定义：索引扫描是利用索引来检索数据的方式。

索引：

索引是一种有序的数据结构，类似于书籍的目录，可以快速定位到表中的特定行，而无需扫描整个表。

在 OceanBase 中，索引是一个 B+ 树的结构，索引上的记录按照索引键值进行有序存放。

过程：

当查询语句提供了索引键的查询条件时，数据库通过索引树的有序结构可以方便地定位到查询的记录或记录的范围，提供高效的索引访问。

OceanBase 的索引中保存了记录的主键值，索引扫描后通过主键值从表中访问对应的记录。

索引类型：OceanBase 数据库中的索引可以分为全局索引、局部索引和空间索引。全局索引和局部索引是分区表上的索引类型。

局部索引（又名分区索引）：是针对单个分区上的数据创建的索引。因此，局部索引的索引键值跟表中的数据是一一对应的关系。

全局索引：是把分区表当做一个整体创建出来的索引。全局索引和表的分区不是一一对应的。

分区表的索引扫描：对分区表的访问也可以使用索引扫描。索引匹配 (Index Matching)

最左匹配原则：

如果索引包含多个列，则按照从左到右的顺序依次排序。

使用索引匹配需要满足最左匹配原则，即按照索引字段的顺序对查询条件进行逐一匹配。

只有在查询条件中提供了索引第一个键值的匹配后，才有可能继续对索引第二键值去做匹配。

最左匹配原则要满足等值匹配，不能是范围查询。

范围查询的限制：

如果在索引的第一个字段上进行范围查询，那么查询条件中后续字段的等值匹配将无法使用索引。

例如，如果有一个在三个字段 C1、C2、C3 上创建的索引，如果 C1 上查询的条件是一个范围，比如 C1 > 100，那么查询条件 C2 = 1 将不能做索引的匹配。

排序：如果查询语句需要对结果进行排序，且排序要求与索引键的顺序完全一致，那么使用索引扫描还可以避免排序。

分区索引的查询条件：使用局部索引查询数据时，需要在查询条件中指定索引键的匹配条件外，还需要提供分区的范围条件。

】

分区的部分，课程中介绍了关于分区，分区查询，分区索引的一些概念如：

分区 (Partition)

在分布式数据库中，需要对表的数据进行合理的分片及分区。通过对表按一定的规则进行分区，把一张表的数据拆分到不同的分区。OceanBase的负载均衡能力将不同的分区分布到不同的服务节点上。

使用分区有助于分布式计算的性能。例如，对表进行全表扫描，因为不同的分区位于不同的服务节点上，可以同时在多个节点执行分区级的扫描，提高查询的性能。

使用分区还有助于数据的维护管理。例如，按时间范围对表中的数据分区，将不同年份的数据存放到不同的分区。如果需要清理过期数据，只需要对相应的数据分区进行清空或删除即可。

访问的数据只存在于某一个或几个分区，最好的方式是只对相关的分区进行查询，而不去访问无关的分区。

分区查询数据

OceanBase 提供了两种按分区查询数据的方式：

在查询语句里指定需要访问的分区。如果要查询students表的P1分区的数据，可以直接在SELECT语句中的FROM表明后显式地指令分区名PARTITION P1。

数据库自动进行分区裁剪及根据WHERE条件中分区键的查询范围与表的分区定义进行匹配，筛选出需要访问的分区。例如，如果Students表是按照sid的范围分区的，当查询语句在WHERE条件中指定sid的范围在2022999999与2023999999之间时，则根据分区范围的定义，数据库知道这个查询只需要访问P1分区。

分区表上创建索引

分区表上的索引分为局部索引和全局索引两种类型。

局部索引（又名分区索引）：是针对单个分区上的数据创建的索引。因此，局部索引的索引键值跟表中的数据是一一对应的关系。

创建局部索引需要在DDL语句中指定LOCAL关键字。

局部索引与对应的分区位置绑定在一起，分区的leader位置即是局部索引的leader位置。

如果我们想使用局部索引来查询数据，在查询条件中除了指定索引键的匹配条件外，还需要提供分区的范围条件。例如，要查找name=Betty的学生，需要在WHERE条件中指定name=Betty，并且指定Betty所在的分区。

如果查询语句中没有指定分区的查询范围条件，使用局部索引查询时，会在局部索引的所有分区同时进行索引扫描，查询的性能要比指定分区的局部索引扫描差。

全局索引：是把分区表当做一个整体创建出来的索引。全局索引和表的分区不是一一对应的。全局索引可以是不分区的，即整个只有一棵索引树，全局索引也可以分区，且其分区方式不需要与表的分区方式一致。

全局索引与表分区是独立的，可以把全局索引与其对应的表当做存在数据关联的两张表。

执行DML操作时，对全局索引的修改和对表分区的修改往往要跨节点，执行效率相对于局部索引要低。

当查询语句不能指定分区键或者分区范围的时候，用全局索引也可以方便地找到对应的分区去做访问。

当我们使用这个全局分区索引去查询name=Betty的数据时，首先根据全局索引的分区定义OceanBase数据库对全局索引的访问做分区裁剪，仅需访问全局索引的P0分区。然后根据Betty对应记录的组件到表分区P1做主键匹配查询，获取到完整的记录。

建议在分区表上默认创建局部索引，除非特殊要求才创建全局索引。选择全局索引而非局部索引的一个最常见的理由是为了保证唯一索引的全局唯一。

如果唯一索引不包含表的分区键，当把这个唯一索引创建为局部索引时，它只能保证局部唯一即分区内唯一。只有将这个唯一索引创建为全局索引，才能保证全局唯一，因为全局索引是把所有分区当做一个整体来创建的索引。

在执行计划和执行计划缓存以及执行计划刷新与淘汰的部分，教学内容介绍了

执行计划 (Execution Plan)

定义: 执行计划，也称为访问路径，描述了数据库执行查询时搜索、匹配、记录、运算查询结果的方法。SQL 引擎的核心能力是选择最佳的 SQL 执行计划。

目标: 最佳的执行计划通常是指访问代价最低、执行性能最好的路径。

单表访问的执行计划类型:

全表扫描 (Table Full Scan)

索引扫描 (Table Range Scan)

主键唯一查询 (Table Unique Scan)

在所有单表访问的查询路径中，主键唯一查询的性能无疑是最好的。

分布式数据库的执行计划:

OceanBase 分布式数据库选择最优执行计划的难度大于传统集中式数据库，因为它不仅要像集中式数据库那样考虑表或索引的访问效率，还需要考虑数据的实际分配情况以及不同节点间的数据交互。

根据跨节点访问的特征，SQL 执行可以分为三种执行计划：本地计划、远程计划和分布式计划。

本地计划: 不需要跨节点访问和执行的计划。

远程计划: 如果 SQL 要访问的数据在远程的另一个 OBServer 节点上，则是远程执行。

分布式计划: 如果 SQL 要访问的数据分布在多个 OBServer 节点上，则是分布式计划。

同一条 SQL 根据其需要访问的数据不同，可能同时具有三种类型的执行计划。

执行计划提示 (Optimizer Hints):

OceanBase 提供了执行计划提示的能力，即优化器。可以通过在 SQL 语句中指定 hint 来告诉优化器更倾向于哪个执行计划。

在单表访问时，可以给优化器一个 hint，指明访问使用的索引名称。在情况许可的条件下，优化器会尽量用 hint 指定的索引生成执行计划。执行计划缓存 (Plan Cache)

目的: 减少 SQL 硬解析的次数，提高执行性能。

原理:

相同的业务处理通常使用相同的一批 SQL。如果 SQL 引擎每一次 SQL 执行都生成一个执行计划，双重执行计划的耗时会严重拖累业务处理的性能。

OceanBase 数据库提供了执行计划缓存的功能。当一条 SQL 第一次解析并生成执行计划后，该执行计划会缓存在 plan cache 中。

当再次执行相同的 SQL 时，数据库会复用 plan cache 中缓存的执行计划，避免了 SQL 硬解析，提升 SQL 的执行性能。

SQL 参数化:

为了减少 SQL 硬解析的次数，提高 plan cache 中执行计划的复用次数，OceanBase 数据库在解析 SQL 时会首先执行 SQL 的快速参数化，把查询条件中的值用参数来代替，并把参数化后的 SQL 文本换算成唯一的 SQL ID。

只要 SQL ID 相同，就可以复用执行计划。执行计划刷新与淘汰 (Plan Cache Refresh and Eviction)

执行计划刷新:

在某些场景下，可能不希望一直复用缓存在 plan cache 中的某个执行计划。例如，新建了一个索引，希望数据库优化器可以重新选择执行计划来使用新建的索引。

OceanBase 提供了计划缓存的刷新机制。在发生 schema 变更、统计信息变化时，会主动将 plan cache 中对应的执行计划置为失效，以便下次执行 SQL 时根据最新的 schema 和统计信息来重新选择执行计划。

执行计划淘汰:

OceanBase 提供了 plan cache 中 plan 的自动淘汰机制。当 plan cache 中缓存的 plan 越来越多时，OceanBase 会根据一定的规则去淘汰较长时间没有使用的 plan，以免新生成的 plan 因为内存问题而无法被缓存。

OceanBase 也提供了手动进行计划缓存淘汰的命令，用户可以主动将特定的租户 database 或者 SQL 语句的计划缓存淘汰掉。

image

image

image

ceanBase的存储引擎融合了传统数据库与新一代数据库以及内存数据库的技术优点，实现了远高于传统数据库的写性能和接近于传统数据库的读性能。传统数据库存储引擎 vs. 新一代数据库存储引擎传统集中式数据库（如MySQL和Oracle）与新一代数据库（如LevelDB和RocksDB）在存储引擎方面的主要区别如下：

数据存储方式

传统数据库：通常使用堆文件组织的方式来存储数据。

新一代数据库：采用LSM树（Log-Structured Merge Tree）的存储架构。

数据更新策略

传统数据库：采用原地更新的策略，即在磁盘上只保留一份数据版本，数据的读写在相同的内存及缓冲池中执行，并且内存中的数据页面与磁盘中的数据页面一一对应。

新一代数据库：采用追加写入增量数据的方式，将增量数据顺序落盘，磁盘上同时保留多个数据版本。

对读写操作的影响

传统数据库：原地更新策略对读操作比较友好，因为磁盘中只保留一份数据，检索数据时不需要查询多个版本的数据，查询性能较好。但对写操作不友好，因为即使只修改内存页面中的一条记录，更新数据落盘时也需要将整个页面写到磁盘，产生写放大的问题，且更新数据落盘时必须将页面覆盖写入到磁盘上相应的位置，不能顺序地写入，产生大量的随机写入。

新一代数据库：LSM树存储架构采用追加写入增量数据的方式，将增量数据顺序落盘，解决了传统存储引擎的随机写和写放大的问题。但因为追加写入增量的方式，导致一份数据副本在磁盘和内存里存在多个数据版本，在读取一个最新的完整的数据版本时，数据库可能要检索多个版本的数据，读操作的访问路径变长，性能变差。

对硬件的影响

传统数据库：随机写与写放大也会损害SSD磁盘的使用寿命。 OceanBase存储引擎的特点

OceanBase的存储引擎采用了LSM树的存储架构，因此也是读写分离的设计，并通过顺序追加写在磁盘上保留多个数据版本，解决了传统存储引擎的写操作问题。

OceanBase使用多级缓存来将不同维度的热点数据保留在内存中，大幅缓解了新一代存储引擎的读性能问题。

OceanBase可以同时从写内存、读内存与磁盘中读取数据，并保证数据的一致性。

OceanBase像传统数据库一样，使用REDO日志来记录数据的变更，通过WAL（Write-Ahead Logging）机制确保了数据更新的持久性。

OceanBase的磁盘数据按主键有序排列，磁盘需按自研压缩编码，提供大比例的数据压缩，大幅降低磁盘成本

OceanBase 融合了传统数据库、新一代数据库以及内存数据库的技术优点，它使用 LSM 树（Log-Structured Merge Tree）的存储架构，加准内存数据库的方式，实现了远高于传统数据库的写性能和接近于传统数据库的读性能。关于 LSM 树存储，内容包括：

LSM 树存储架构是读写分离的设计。

LSM 树存储架构通过顺序追加写在磁盘上保留多个数据版本，解决了传统存储引擎的写操作问题。

LSM 树存储架构中，数据更新使用写内存，每个分区在 maps 中以 map 的形式存在，Ma table 中缓存的是该分区增量数据，也叫动态数据。

LSM 树存储架构中，动态数据落盘后以 ss table 的形式存储在磁盘上，Ss table 中的数据不能被应用直接修改，所以 ss table 数据成为静态数据。关于准内存数据库，内容包括：

OceanBase 使用多级缓存来将不同维度的热点数据保留在内存中，大幅缓解了新一代存储引擎的读性能问题。

OceanBase 可以同时从写内存、读内存与磁盘中读取数据，并保证数据的一致性

OceanBase中，关于动态数据memtable的内容如下：

LSM树架构将数据的读取和写入分开，数据的更新使用写内存，称之为maps。

每个分区在maps中以map的形式存在，MemTable中缓存的是该分区的增量数据，也叫动态数据。

为了加快数据检索的速度，OceanBase在MemTable的内存结构中同时构建B树和哈希（Hash）两种数据结构。

当进行等值条件的查询时，可以用哈希算法直接在哈希表中找到相应的记录。

如果查询条件是一个范围时，则可以通过访问B树来快速找到对应的数据范围。

当我们对一条记录执行修改后，新的数据版本会与旧的数据版本链接在一起，在MemTable中形成一个多版本记录的链表，链表每一个节点都会保留其某一个历史的数据版本。多版本数据的控制机制叫做MVCC（Multi-Version Concurrency Control）。通过这样的机制，可以实现对历史数据的访问。

LSM树架构中数据的更新都在MemTable中完成。

当动态数据的内存占比达到一定量时，OceanBase会将这些动态数据写入到磁盘上，转变为静态数据，这个过程叫做转储。 ◦ 转储有两个作用：

及时释放内存，如果不及时将动态数据落盘，可能会导致内存紧张。

为了发生故障时的快速恢复，如果长时间不对动态数据落盘，当机器出现宕机等故障时，内存中的数据就丢失了，机器重启后需要通过日志来进行恢复数据。

转储的发起有两种方法：

自动触发：当一个租户的MemTable内存使用量达到设定的阈值时，OceanBase自动对触发的租户和OBServer执行转储。

手动触发：由用户发起命令来手动执行。

OceanBase在转储时不会将动态数据直接与磁盘上的数据做归并，数据的归并由自动发起的后台任务根据转储的次数和数据量来分层执行。

L0层转储时，OceanBase数据库首先对内存中的MemTable做冻结。冻结后，MemTable中的数据只能读取，不能再写入，冻结的MemTable落盘，形成一个小小的增量数据文件，称之为mini SSTable，并将这些mini SSTable称为L0层

OceanBase中，关于静态数据 SSTABLE 与数据落盘转储的内容总结如下：

静态数据（SSTable）

在LSM树架构中，动态数据从MemTable落盘后，以 SSTable 的形式存储在磁盘上。

SSTable 中的数据不能被应用直接修改，因此 SSTable 数据被称为静态数据。

SSTable 的物理结构是用宏块（宏块）和微块（微块）组合。

宏块是2MB大小的数据块，是磁盘文件上写IO的基本单位。由于OceanBase默认使用压缩存储，宏块是一个压缩后大小为2MB的数据块。

铜块儿内是以微儿的形式来组织。

微块内保存真实的数据记录，是磁盘文件上读IO的基本单位。微块在压缩前的默认大小是16K，但压缩后的长度不固定。

数据落盘转储

当动态数据的内存占比达到一定量时，OceanBase会将这些动态数据写入到磁盘上，转变为静态数据，这个过程叫做转储。

转储有两个作用：

及时释放内存，如果不及时将动态数据落盘，可能会导致内存紧张。

转储的发起有两种方法：

自动触发：当一个租户的MemTable内存使用量达到设定的阈值时，OceanBase自动对触发的租户和OBServer执行转储。

手动触发：由用户发起命令来手动执行。

OceanBase在转储时不会将动态数据直接与磁盘上的数据做归并，数据的归并由自动发起的后台任务根据转储的次数和数据量来分层执行。

根据转出文件的规定次序，增量数据文件分为以下三层：

L0层：转储时，OceanBase数据库首先对内存中的MemTable做冻结。冻结后，MemTable中的数据只能读取，不能再写入。冻结的MemTable落盘，形成一个小小的增量数据文件，称之为mini SSTable，并将这些mini SSTable称为L0层。

L1层：当L0层的mini SSTable购数量达到阈值时，OceanBase数据库会自动将这些mini SSTable压缩成一个文件，称之为minor SSTable即是L1层。

L2层：该层保存的是产生这些增量数据之前的基线数据版本，称为major SSTable。

OceanBase 中，关于数据合并和数据压缩的内容及分析总结如下：数据合并

目的：随着增量数据不断写入磁盘，增量数据文件越来越多，为了获得最新的完整数据版本，需要检索的增量数据文件也越来越多，导致读操作性能降低。

过程：OceanBase 会在合适的时机将所有增量数据与之前的基线数据做合并，形成一个统一版本的新基线数据，这个过程称为合并（Major Compaction）。

结果：合并后生成的 Major SSTable 不包含多版本数据，所有数据记录都属于同一个版本。合并后，在新的增量数据产生之前，对数据的访问可以直接从 Major SSTable 获取，不需要访问碎片化的增量数据文件，从而大幅提升读操作的性能。

时机：合并涉及到大批量的数据读写，是一个比较耗时的操作，通常不在业务执行过程中执行合并。数据压缩

目的：节省数据在硬盘上的存储空间。

过程：在合并时，OceanBase 数据库会对 SSTable 中的数据进行两次压缩：

第一次压缩是编码压缩：OceanBase 自研的编码算法可以在不损失性能的前提下实现比较高的压缩比。

第二次压缩是通用压缩：OceanBase 会自适应的选择合适的压缩算法对数据进行压缩，比如 Snappy, LZ4, ZSTD 等。

结果：经过两次压缩，OceanBase 可以实现领先行业的压缩性能和压缩比，大幅降低磁盘空间的需求，降低存储成本。分析

数据合并通过整合增量数据和基线数据，减少了读操作需要访问的文件数量，从而提高了读性能。

数据压缩通过编码压缩和通用压缩两种方式，提高了数据的存储效率，降低了存储成本。

OceanBase 通过数据合并和数据压缩，在保证读写性能的同时，实现了低存储成本的目标。

根据提供的源文件，以下是关于OceanBase数据库中事务并发、隔离级别和锁机制的总结：事务并发控制

目标：确保在多个并发执行的事务读写相同数据时，避免事务之间的相互干扰，防止数据不一致或其他异常。

问题：并发事务可能导致脏读、不可重复读和幻读等问题。

脏读：一个事务读取到其他事务尚未提交的数据（即脏数据）。

不可重复读：事务在执行过程中，重复读取同一批数据时，发现数据已被其他事务修改，无法重复读到完全一样的数据。

幻读：事务在执行过程中重复读取一批数据时，发现数据集中的记录数量发生了变化，例如第二次读取时看到了第一次读取时不存在的记录。

OceanBase的解决方案：OceanBase通过锁机制、多版本并发控制（MVCC）事务隔离级别来控制多个事务的并发操作，以保证数据库事务的ACID属性。隔离级别（Isolation Level）

定义：隔离级别用于描述事务并发执行时互相干扰的程度。

SQL标准定义的四种隔离级别：

读未提交（Read Uncommitted）：事务中的查询可以看到其他事务尚未提交的数据。OceanBase不适用此隔离级别，因为可以使用多版本数据来避免等待。

读已提交（Read Committed）：查询读取到的数据都是在执行查询时已经完成提交的干净数据。可能出现不可重复读和幻读。

可重复读（Repeatable Read）：在事务执行的过程中，相同的查询重复执行时读取到的数据是一样的。避免了脏读和不可重复读，但不能防止幻读的发生。

可串行化（Serializable）：事务中的查询只能看到事务开始之前提交的数据，并且在事务的执行过程中，这些数据不能被其他事务修改。这是最严格的隔离级别，可以防止脏读、不可重复读和幻读。

OceanBase的隔离级别支持：

OceanBase的Oracle租户和MySQL租户的隔离级别分别与Oracle数据库和MySQL数据库保持一致。

MySQL租户支持读未提交之外的前三种隔离级别。

Oracle租户只支持读已提交和可串行化两种隔离级别。锁机制

锁的级别：OceanBase提供表锁和行锁两个级别的锁。

表锁：用于锁定整个表。表锁有不同的互斥等级，有的表锁是相容的，而有的表锁则是排他性的。

行锁：用于锁定单个行。只有在对行进行更新时才会获取，因此行锁是排他性的锁，而读取数据是无需加行锁的。

锁的应用：

在执行DML语句进行数据更新操作时，OceanBase不仅会在更新的行上加排他性的行锁，还会在表上加与其他DML相容的表锁。

DDL操作通常会在表上加排他性的表锁。

通过表锁与行锁，OceanBase实现对DML和DDL的并发控制，确保数据的一致性和完整性。 MVCC（多版本并发控制）OceanBase通过MVCC实现了读不加锁，以避免读写冲突，OceanBase存储数据的多个版本，在读取数据时，可以根据事务的隔离级别、查询语句的读版本号和数据的提交版本号来判断应该读取哪一个版本的数据，MVCC机制创建新版本数据，同时保留旧版本数据。

分布式事务

分布式事务的参与者角色被划分为协调者与参与者两种.协调者只有一个，它负责发起事务的提交或回滚.参与者可以有多个，他们根据协调者的指令来提交或者回滚事务

网络通信不可靠：在事务提交过程中，协调者向参与者发送的请求或参与者回复的请求可能无法送达，需要考虑如何处理这种情况。

节点故障的影响：当事务的某个参与者节点发生故障时，分布式事务处理系统需要能够快速检测到故障，并将事务恢复到正确的状态，以保证数据的一致性。OceanBase 通过 Paxos 一致性协议确保事务的协调者和参与者都是多副本、高可用的，并且通过超时和重试机制来预防网络延迟或节点故障。当参与事务处理的节点发生故障时，OceanBase 会在 8 秒内自动进行 leader 的改选，新的 leader 上任后能够自动推进尚未完成的事务执行。

数据一致性的挑战：多个节点同时参与事务处理时，必须保证所有参与者的事务状态保持一致。分布式数据库需要应对并发操作、网络延迟、节点故障以及时钟差异等因素带来的数据持续性和一致性的挑战。

性能下降的挑战：跨节点的事务处理会受到节点之间距离和网络传输速度的影响，导致分布式事务的执行和提交性能低于单机事务。OceanBase 在标准的两个阶段提交协议的基础上，基于分布式架构的特点，对事物提交流程做了优化，减少了协调者与参与者之间的通讯等待，提升了分布式提交的性能。

时钟差异：分布式架构下，集群中的服务器有各自的时钟，可能导致并发数据访问时发生逻辑错误和数据不一致。为解决时钟差异问题，OceanBase 提供全局时间戳服务（GTS），保证所有版本号单调向前，并与真实世界的时间顺序保持一致。

事务处理复杂性：在分布式架构下，事务的提交需要多个参与者共同完成，并且需要在多个副本之间同步，处理过程变得非常复杂。总的来说，OceanBase 通过一系列架构与理论的创新，包括全局时间戳服务 GTS、优化的两阶段提交协议、Paxos 一致性算法以及自动的故障恢复机制等，解决了分布式架构下的事物处理的挑战，支持高并发、低延迟的事物处理，同时保证数据的一致性和完整性。

标准两阶段提交 (Two-Phase Commit, 2PC) 流程：

准备阶段 (Prepare Phase)：协调者 (Coordinator) 向所有参与者 (Participants) 发送准备请求 (prepare request)，并等待他们的响应。参与者在这个阶段需要将操作结果记录在事务日志中，但并不真正提交事务。 ◦ 提交阶段 (Commit Phase)：如果所有参与者都能完成准备提交的任务，协调者会向所有参与者发送正式提交命令。如果任意参与者不能完成准备提交的任务，协调者会通知所有参与者回滚事务。

缺点：多次交互：协调者与参与者之间需要进行多次互动。

性能较差：在分布式架构下，多次网络交互导致事务提交的性能较低。

OceanBase 的创新两阶段提交

优化：减少通讯等待：OceanBase 在标准两阶段提交协议的基础上，针对分布式架构的特点对事务提交流程进行了优化，减少了协调者与参与者之间的通讯等待。

提升性能：通过减少协调者与参与者之间的通讯，提升了分布式提交的性能。

优势：高可用容错：OceanBase 的两阶段提交协议在保证事务原子性的同时，还提供了事务的高可用容错能力和故障恢复能力。

Paxos 一致性：OceanBase 通过 Paxos 一致性协议确保事务的协调者和参与者都是多副本、高可用的。

超时和重试机制：OceanBase 通过超时和重试机制来预防网络延迟或节点故障导致的事务执行与提交问题。

自动故障恢复：当参与事务处理的节点发生故障时，OceanBase 会在 8 秒内自动进行 leader 的改选，新的 leader 上任后能够自动推进尚未完成的事务执行。总结 OceanBase 在标准两阶段提交的基础上，通过减少通讯次数、引入 Paxos 一致性协议、增加超时重试机制和自动故障恢复等创新，解决了分布式事务处理中的性能和可靠性问题

OceanBase的分布式事务引擎通过一系列架构与理论的创新，解决了分布式架构下的事务处理的挑战。它支持高并发、低延迟的事物处理，同时保证数据的一致性和完整性。分布式事务的参与者角色被划分为协调者与参与者两种。协调者只有一个，它负责发起事务的提交或回滚。参与者可以有多个，他们根据协调者的指令来提交或者回滚事务。以下是 OceanBase 解决分布式事务挑战的一些关键机制：

全局时间戳服务（GTS）：为了解决分布式架构下服务器时钟差异可能导致的数据不一致问题，OceanBase 提供了全局时间戳服务（GTS）。事务在修改或查询数据时，都会从 GTS 获取版本号，保证所有版本号单调向前，并与真实世界的时间顺序保持一致。OceanBase 会为每一个租户都开启一个独立的 GTS 服务，每一个 GTS 服务均可以处理每秒百万次的请求。GTS 是一个高可用的架构，它的服务副本个数与租户的副本数一致。如果 GTS 的节点发生故障，OceanBase 会自动将 GTS 服务切换到其他可用的服务副本上。

优化的两阶段提交协议：OceanBase 在标准的两阶段提交协议的基础上，基于分布式架构的特点，对事物提交流程做了优化，减少了协调者与参与者之间的通讯等待，提升了分布式提交的性能。

Paxos 一致性算法：OceanBase 通过 Paxos 一致性协议确保事务的协调者和参与者都是多副本、高可用的。

自动的故障恢复机制：OceanBase 具备自动故障恢复能力。当参与事务处理的节点发生故障时，OceanBase 会在 8 秒内自动进行 leader 的改选，新的 leader 上任后能够自动推进尚未完成的事务执行。

超时和重试机制：OceanBase 通过超时和重试机制来预防网络延迟或节点故障导致的事务执行与提交问题