Release v4.2.0_CE_BETA · oceanbase/oceanbase

V4.2.0_CE_Beta

版本信息

项目	描述
发布日期	2023-08-02
版本号	V4.2.0_CE_Beta
Commit 号	8024d8f
OBServer RPM 版本号	oceanbase-ce-4.2.0.0-100000152023080109

版本定位

OceanBase 数据库 V4.2.0_CE 版本是在 V4.1.0_CE 版本基础上进一步健全完善核心特性，补齐了 V3.x 系列的全部主要功能，提升产品可扩展性，优化资源使用，提高性能，增强兼容性与易用性。目前发布的为 V4.2.0_CE Beta 版本，而后续的 V4.2.x 版本也会作为 长期支持版本（LTS） 对外提供服务。
V4.2.0 版本核心特性如下：

MySQL兼容
- 函数索引：新版本在 MySQL 模式下也支持了兼容 MySQL 8.0 的函数索引，同时进一步增强了函数索引的使用稳定性。
- OBCDC：行数据支持按照列的定义序输出，满足 MySQL Binlog Service 的兼容性需求。取消系统租户依赖，支持普通租户同步，支持无主键表同步。
性能提升
- 优化器/执行器/ PL 能力增强：新版本针对查询改写、查询优化能力做了一系列增强，也重点优化了执行器算子性能。PL 优化了 Plan Cache 和并行执行逻辑，支持 SQL 语句返回复杂数据类型。
- 统计信息强化：增强统计信息功能的稳定性和可用性。同时增加了统计信息收集监控诊断功能，优化了统计信息收集的性能和内存开销。
- 动态采样：支持了优化器动态采样功能，在 SQL 运行时收集统计信息，生成更优的执行计划，提升查询性能。
- 查询计划演进：支持查询计划演进功能，有效避免执行计划性能回退。
- Runtime Filter：完整支持 Runtime Filter，提升 AP 处理性能。
- 4C 小规格性能优化：4C 环境默认参数下，OLTP 各个场景性能提升 20%+。
- 读事务数据性能优化：优化读转储未提交数据时的查事务表性能。
- 事务数据表并行转储：V4.1.0 版本已经支持了并行的 MINOR_MERGE（表示多个 Mini SSTable 合成一个 Minor SSTable），V4.2.0 版本新增支持对事务数据表做并行的 MINI_MERGE（表示冻结 MemTable 通过转储变成 Mini SSTable）。
- 快速随机数据生成：新增 GENERATOR(N) 内置函数，可配合 RANDOM([N])、RANDSTR(N, gen) 随机函数或 NORMAL(<mean> , <stddev> , <gen>)、UNIFORM(<min> , <max> , <gen>)、ZIPF(<s> , <N> , <gen>) 等分布控制函数使用。相对 MySQL Recursize CTE，Table Generator 具备明显的性能优势。
OLAP能力
- 只读外表：创建、读取，减少数据入库开销。
扩展性增强
- Transfer和负载均衡：采用 Transfer 技术实现日志流的分裂和合并，支持以分区为单位进行跨节点的数据搬迁，提供了灵活的扩缩容能力和数据动态均衡能力。
- 复制表：新版本基于单机日志流的新架构对复制表进行了重构，构建了基于分区的可读版本号校验以及基于日志流的 Lease 授予机制，用于保证强一致性读的正确性。另外，新版本完善了切主不杀事务的能力，在用户或负载均衡发起 Leader 切换时未提交的复制表事务可以在切主后继续执行。相比于 V3.x 版本，V4.2.0 版本的复制表也有着更好的写事务性能和更强的容灾能力，副本宕机对于读操作的影响更低。
高可用增强
- 物理备库：OceanBase 数据库 V4.1.0 版本支持了基于归档的主备库，配置灵活且不要求主备租户之间网络。但仍然有不少场景需要基于网络直通的主备库方案，来降低存储及网络成本，缩减备份恢复链路，V4.2.0 版本进行了扩展支持。
- 日志写入限速：日志提交写盘的速度大于转储速度时会导致日志盘满。V4.2.0 版本在日志盘使用量达到一定水位时，通过限制日志提交写盘的速度，来避免写入压力特别大的集群频繁出现日志盘满的现象。相关用法请参考 log_disk_throttling_percentage/log_disk_throttling_maximum_duration 配置项。
资源使用优化
- 空载 CPU 优化：针对高频、耗时长的 SQL、后台线程做了一些针对性的优化，以降低内部 SQL 执行和后台线程定期执行的 CPU 开销。经测试，单个业务租户，30 张压测表，单表数据 100w 行的空载环境下，CPU 默认开销 0.2C 左右。
- 磁盘数据文件按需扩展：支持渐进磁盘扩容方式，先预分配一个合适的磁盘大小，然后根据实际使用情况自动扩容。
- 共享内存识别机制：在技术手段上增加防御机制，对真正预期使用共享内存的代码进行打标，优化随代码合入出现的共享资源增多情况。
易用性提升
- Auto DOP：支持 Auto DOP 自动计算查询并行度，降低并行执行使用门槛。
- 全链路诊断能力增强：V4.1.0 版本提供了全链路诊断能力，V4.2.0 版本基于全链路诊断框架, 又补充了部分 Trace 打点信息。同时提供了面向事务+SQL 维度的可交互的 Show Trace 能力。
- 逻辑计划管理：V4.2.0 版本为逻辑计划易用做了很多改进。比如保存 EXPLAIN 计划信息、逻辑计划的执行反馈信息、查询运行中 SQL 的实时计划；提供丰富的 DBMS_XPLAN 包接口，展示指定查询的计划、Baseline 计划、及 Session 的实时计划，并以格式化方式输出。
- 后台线程统计：V4.2.0 之前版本更倾向以客户端为视角，记录前台线程诊断信息。但对OceanBase 数据库来讲，后台线程占了绝大部分，不论排查问题还是诊断性能，都需要了解后台线程的状态。V4.2.0 版本新增视图 [G]V$OB_THREAD，用于记录全量线程的状态信息。
国家标准

GB18030-2022 字符集：OceanBase 数据库在 V4.2.0 版本开始支持 GB18030-2022 字符集。GB18030-2022 在 2022 年 7 月 19 日发布，2023 年 8 月 1 日正式实施，支持了更多的生僻汉字及少数民族文字，成为信息系统的全文强制执行标准。

产品形态
- 产品主备库：V4.1.0 支持了单机形态，V4.2.0 补充支持单机主备库形态。
- 只读副本（R 副本）：V4.2.0 版本补齐了只读副本功能，区别于全功能副本，提供只读能力。

关键特性说明

MySQL兼容

支持函数索引： MySQL 8.0 新增函数索引功能，主要用于优化查询语句的性能。通常情况下，如果对查询列使用了函数或表达式，那么无法使用普通的索引进行优化，需要使用函数索引来提高查询性能。函数索引可以将函数的返回值作为索引的一部分，从而加快查询速度。OceanBase 数据库 V4.2.0 版本开始也在 MySQL 租户下支持了 MySQL 8.0 兼容的函数索引，支持通过 create table/create index/alter table 等语句创建。另外，V4.2.0 版本也强化了索引的抽取能力，在索引表达式外层存在隐式转换、前缀索引的引用列上存在 Like 谓词等多数场景可以有效使用到索引。更多信息请参见创建索引。

性能提升

统计信息强化

V4.0.0 版本之后统计信息的收集完全由 SQL 层发起和维护，合并时不再收集统计信息。但由于统计信息收集功能不够完善，在收集的性能和内存消耗上等方面存在一些问题，进一步影响到 SQL 计划的生成。同时由于统计信息的收集缺乏有效的监控手段，用户难以确定各个数据表上统计信息收集的状态、是否过期等信息，会造成运维困难。V4.2.0 版本重点增强了统计信息功能的稳定性和可用性。在线统计信息收集优化了数据结构和收集性能，INSERT INTO SELECT 和 LOAD DATA 两种导数方式使用在线统计信息收集时性能提升 10% 左右。离线统计信息收集优化了计划生成路径和内存使用，在 tpcds_100g 分区表、64 并发离线收集场景，性能提升 10%-20%。另外还支持了统计信息收集监控诊断，新增 [G]V$OB_OPT_STAT_GATHER_MONITOR 动态性能视图用于查询统计信息收集任务实时状态，新增 DBA_OB_TASK_OPT_STAT_GATHER_HISTORY 字典视图用于查询历史收集任务执行情况，新增 DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY 字典视图用于查询表的历史收集执行情况。

动态采样

在执行 SQL 查询时，OceanBase 数据库优化器需要收集表和索引的统计信息，以便能够选择最佳的执行计划。如果统计信息不准确或者不完整，使用的执行计划就可能不是最优的，导致查询性能下降。基础的统计信息通常是通过自动收集或者手动收集等方式获取到。但是，如果数据分布发生变化，没有收集统计信息或者遇到一些复杂的 SQL 查询，统计信息就可能不再准确。V4.2.0 版本提供了动态采样功能，在计划生成阶段针对数据库对象进行提前采样，通过采样的方式进行行数估计，从而用于代价模型中，生成更好的执行计划。目前提供了系统变量、查询 HINT 及系统配置项三种方式进行动态采样功能的控制，同时采样集的大小受限于并行度的控制。更多信息请参见优化器动态采样。

Runtime Filter

OceanBase 数据库自 V3.1.0 版本以来, 支持了 Join Bloom Filter 用于在 Join 中执行期扫描数据时快速过滤数据, 在 V4.0.0 版本上对于 Join 键为分区列或者分区列前缀场景支持了Partition Bloom FIlter可以动态过滤分区，在 V4.1.0 版本支持了多发 Bloom Filter 使得相邻 DFO 和单个 DFO 内部均可以生成多对 Bloom Filter。 In/Range/Bloom Filter 这一类在执行期动态过滤数据的 Filter 统一称为 Runtime Filter(RF)，V4.2.0 版本完整支持了 Runtime Filter，提升 AP 处理性能。可以通过px_join_fitler / px_part_join_filter 来手动打开 runtime filter/part filter；通过no_px_join_filter / no_px_part_join_filter 来手动关闭 runtime filter/part filter。并提供了 4 个系统变量用于在需要场景下调整 Runtime Filter 执行相关策略。更多信息见 Runtime Filter。

4C 小规格性能优化

结合自增 ID 优化、New Sort 自适应优化、PDML 场景下 Callback Allocator 优化、时间函数调用优化、单日志流语句快照获取优化、租户级别获取优化、enable_trace_log/enable_sql_audit 优化等优化手段，V4.2.0 版本对 4C16G 小规格场景的 Sysbench 压测性能提升 20%+。

快速随机数据生成

Table function 是一种能够返回一张数据表作为结果的函数。在此基础上，V4.2.0 版本新增 Table Generator 功能，即 generator(N) 内置函数，并允许在 Table Function 中调用它，表现为 table(generator(N))。同时新增 RANDOM([N])、RANDSTR(N, gen) 随机函数，和 NORMAL(<mean> , <stddev> , <gen>)、UNIFORM(<min> , <max> , <gen>)、ZIPF(<s> , <N> , <gen>) 分布控制函数，与 Table Generator 配合使用生成数据。相对 MySQL Recursize CTE，Table Generator 具备明显的性能优势。更多信息请参见 GENERATOR。

OLAP 能力

只读外表

数据库中的表会存放于数据库的存储空间中，而外表的数据存储于外部存储服务中。外部表可以像普通表一样查询，但局限于读，不能执行 DML 操作。通常情况下，处理外部数据，需要先通过 ETL 工具将数据导入数据库。在这个过程中，数据库需要消耗存储空间、磁盘 I/O 和 CPU 等资源。而外部表省略了数据导入的流程，可以直接读取外部数据源进行查询分析。使用方法和限制见创建外表。

扩展性增强

Transfer 和负载均衡

OceanBase 数据库 V4.0.0 版本进行了架构升级，引入了自适应日志流概念，目标是实现单机分布式一体化架构，提供更加灵活的扩展性能力，支持单机和分布式形态的动态变换。已发布的 V4.1.0 版本在扩展性能力方面还不够完善，分区和日志流是静态的绑定关系，不支持动态调整分区分布，从而限制了自动负载均衡的能力，不支持部署形态的灵活变换。OceanBase 数据库 V4.2.0 版本是首个完整实现单机分布式一体化架构的版本，采用 Transfer 技术实现了日志流的分裂和合并，支持了以分区为单位进行跨节点的数据搬迁，完善了可扩展性能力，真正实现了单机和分布式形态的动态变换。租户级别的负载均衡特性主要体现在以下两个方面：

租户水平扩缩容：用户通过动态调整 Unit Number（每个 Zone 上提供服务的 Unit 个数）和 Primary Zone（提供读写服务的 Zone 列表），可以实现租户的读写服务能力在 Zone 内和 Zone 间的水平扩缩容。负载均衡模块将根据用户服务能力的配置自适应调整日志流和分区分布。
分区均衡：在表和分区动态变化的情况下，通过动态调整分区分布，实现分区个数以及存储空间在服务节点上的均衡。

更多信息请参见负载均衡。

复制表

复制表是 OceanBase 数据库的一种特殊表，可以在任意一个 “健康” 的副本上读取到数据的最新修改。对于写入频率较低、更关心读操作延迟和负载均衡的用户来说，复制表是一个很好的选择，在牺牲小部分事务提交性能的前提下复制表可以在任意一个 “健康” 的 Follower 上读到最新数据。此处所提到的“健康”是指 Follower 与 Leader 之间的网络通畅、回放进度差距不大。在 V3.2.0 版本中，OceanBase 数据库已经支持复制表功能，通过复制表可以在指定租户的每台机器上都有一个备副本，并且主副本与所有备份的数据使用全同步策略保持强同步。V4.2.0 版本的复制表相较于旧版本又做出了一些改进，完善了切主不杀事务的能力，在用户或负载均衡发起 Leader 切换时，可以在切主后继续执行。同时，新版本的复制表也有着更好的写事务性能和更强的容灾能力，副本宕机对于读操作的影响更低。
更多信息请参见创建表。

高可用增强

物理备库

V4.1.0 版本支持了基于三方介质归档的主备库，该方案解决了主备库基本需求，并且配置灵活，比如不要求主备租户之间网络互通等。但是相比网络直连备库存在一些劣势，比如存储以及网络成本上升、性能以及稳定性上的损耗、运维难度上升、使用限制如 Switchover 要求备库先开启归档等。从这些方面考虑，基于网络直通的物理备库缩短了主备库间日志同步链路，对单机用户、中小用户等更加友好。另外考虑备库通信的可用带宽限制和不稳定性因素，V4.2.0 版本也支持了备库限速能力，避免在网络带宽受限制时部分备库流量占用过高影响其他节点的情况。物理备库具体使用方式见物理备库概述。

资源使用优化

磁盘数据文件按需扩展

OceanBase 数据库采用预分配磁盘空间的策略，好处是可以保证占有一段尽可能连续的磁盘空间，避免其他应用程序对磁盘的抢占引起的磁盘资源不足，并且可以在其基础上定制文件系统，提高数据访问效率。但用户数据量很小的情况下，会存在磁盘空间浪费的情况。V4.2.0 版本新增加一种渐进磁盘扩容的用户配置选项，即预分配一个合理的磁盘大小，根据磁盘的实际使用情况自动感知并扩容，降低磁盘开销具体使用方式见配置磁盘数据文件的动态扩容。

易用性提升

Auto DOP

并行执行是优化大数据量查询的关键能力，优化器中一般会使用并行度（DOP：Degree of Parallel）来描述并行资源量。在实际业务场景中，是否需要开启并行以及所需的 DOP 大小，历史版本需要考虑执行情况、业务响应时间要求、系统资源等，靠经验通过系统变量或 HINT 来手工调整。在保留手工调整并行度能力的基础上，V4.2.0 版本新增 Auto DOP 功能，在生成查询计划时评估查询需要执行的时间，自动确定是否开启并行，以及对当前查询合适的并行度。并可通过系统变量 parallel_degree_policy 控制 DOP 选择策略。更多信息见 Auto DOP。

全链路诊断能力增强

OceanBase 数据库 V4.2.0 版本在诊断能力上有了显著提升，其中包括首次实现对 SQL 请求的可视化全链路追踪，能够帮助用户快速追踪并定位具体问题发生在哪个执行阶段、哪台机器以及哪个模块，并提供具体的执行信息。提供了面向用户的事务 + SQL 维度的 Show Trace 能力。对于业务部门而言，更关心的往往是一笔业务服务总的耗时情况。例如在 OLTP 系统中，一笔业务服务一般由一个或多个事务组成。因此，我们把事务作为追踪单位会更贴合用户的实际业务，一个事务形成一个追踪的 Trace，并对事务中每条 SQL 请求记录 OBClient > ODP > OBServer 内部全链路过程中相关执行信息，用户可以通过一个 Trace 快速找到该事务执行了哪些语句，以及这些语句从客户端视角看到的执行情况。Show Trace 也可以为用户提供便捷的业务系统关联能力，用户通过 JDBC 接口/ SQL 接口，能够在业务数据库连接上设置调用请求对应的 app trace id, 该 app trace id 会记录到 OceanBase 数据库全链路追踪对应的信息中, 并在 Show Trace 中展示出来。当用户发现某个 app trace id 对应的请求或服务数据库调用有报错时, 可以使用该 app trace id在全链路诊断系统中快速搜索到对应的 app trace id 关联的数据库 Trace，然后直接查看该请求在数据库链路中各阶段耗时情况及报错点，快速确定触发问题的组件。更多信息见全链路追踪展示。

逻辑计划管理

V4.2.0 版本在逻辑计划管理方面做了很多增强功能，包括：

通过 EXPLAIN 语法获取某条查询的计划信息后，在当前 Session 未断开之前，用户可以通过 DBMS_XPLAN.display 查询历史，或者可以通过 EXPLAIN INTO 语法指定保存到目标表。
自动保存执行过的所有查询的计划，包括物理计划以及逻辑计划，方便后续排查问题。重启集群时，数据库会清理保存的查询计划。
通过 DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE 查看 SPM 的基线计划。
通过 DBMS_XPLAN.DISPLAY_ACTIVE_SESSION_PLAN 和 SESSION_ID 查看执行中的查询的计划信息。

更多信息见 DISPLAY_ACTIVE_SESSION_PLAN。

国家标准

GB18030-2022 字符集

GB18030-2022 在 2022 年 7 月 19 日发布，2023 年 8 月 1 日正式实施，并成为信息系统的全文强制执行标准。与 GB18030-2005 标准相比，新标准支持了更多的生僻汉字及少数民族文字。OceanBase 数据库 V4.2.0 版本支持了新标准的字符集 GB18030_2022，也配套更新了相应的排序方法。MySQL 模式下字符集名称为 GB18030_2022，也配套更新了相应的排序方法。。更多信息请参见字符集。

产品形态

单机主备库

V4.1.0 版本支持了单机形态，V4.2.0 版本补充支持单机主备库形态。

只读副本（R 副本）

只读副本不参与一致性协议的投票，无法成为 Leader，只有回放 Leader 产生的日志在本地生成相应的数据。简而言之，只读副本只可能提供读服务，不可能提供写服务。OceanBase 数据库 V4.2.0 版本补齐只读副本功能，结合复制表广播日志流，在不需要参与投票的 OBServer 节点上部署只读副本，在需要参与投票的 OBServer 上部署常规的全功能副本（F 副本），保证在理想情况下复制表可以在任意一个 OBServer 节点上提供强一致性读。
只读副本与全功能副本对比如下：

副本类型	选举投票	日志投票	SSTable	Clog	MemTable
全功能副本	参与	参与	有	有	有
只读副本	不参与	不参与	有	有	有

性能报告

参考社区版本 V4.2.0_CE Beta 的性能测试数据如下：
测试环境规格：

CPU 平台架构	x86_64
ECS 类型	ecs.g7.8xlarge
计算资源	32 核
内存资源	128GB
磁盘资源	300G 系统盘，2*400G 云盘
操作系统	CentOS Linux release 7.9.2009 (Core)

测试版本：

版本	描述
OBServer (V4.2)	OBServer (OceanBase_CE 4.2.0.0) REVISION: 1-b274f1768fb31f46c38e691b2883324b01605b4b BUILD_TIME: Jul 19 2023 08:31:51
ODP (V4.2)	ODP (OceanBase 4.2.0.0 3883.el7) REVISION: 3883-local-b6e947efa65fec48be04f5fb78d70019651503cf BUILD_TIME: Jul 20 2023 09:36:15
OBServer (V4.1)	OBServer (OceanBase_CE 4.1.0.0) REVISION: 100000172023031416-6d4641c7bcd0462f0bf3faed011803c087ea1705 BUILD_TIME: Mar 14 2023 16:53:58
ODP (V4.1)	ODP (OceanBase 4.1.0.0 1) REVISION: 5617-local-e6798c479feaab9f9a60b89f87e4df5e284250b6 BUILD_TIME: Mar 11 2023 21:42:11

测试调优说明：
为了提升用户体验和易用性，以下测试仅基于少量基础常用参数调优，没有进行大范围调优和点对点优化。

SYSBENCH OLTP负载测试

测试方案：

通过 OBD 部署 OceanBase 集群，ODP 和 Sysbench 分别安装在两台机器上, 作为客户端的压力机器，避免资源抢占。其中ODP单独部署在64c128g的机器上（机型ecs.c7.16xlarge ）
OceanBase 集群规模为 1：1：1，部署成功后先新建跑 Sysbench 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），两次测试分别设置租户的 Primary Zone为 RANDOM 和 Zone1，RANDOM 表示新建表分区的 leader 随机到这 3 台机器，Zone1 表示新建表分区的 leader 集中在 Zone1 的 1 台机器上。
启动 Sysbench 客户端，进行 point_select、read_write、read_only 和 write_only 测试。
每轮测试 --time 设置为 60s，线程数取值可以为 32/64/128/256/512/1024。
测试数据量为 30 张非分区表，100 万行数据，即 --tables=30，--table_size 设置为 1000000 。

租户规格：

MAX_CPU = 26
MEMORY_SIZE = 70g

参数调优：

ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

测试结果：

Point Select 性能

Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
32	135146.05	0.27	138746.60	0.26	137423.12	0.27
64	252277.60	0.30	252231.37	0.29	246275.56	0.31
128	431564.13	0.36	447755.19	0.34	377949.26	0.50
256	686271.21	0.55	730315.66	0.48	461791.47	0.94
512	937428.74	0.95	1009966.93	0.90	535462.87	1.67
1024	985232.01	2.35	1012734.80	2.66	537828.40	3.89

Read Only 性能

Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
32	115232.45	4.74	121733.00	4.65	119054.75	4.74
64	214733.98	5.18	221563.16	5.09	208659.70	5.37
128	366616.03	6.09	392138.56	5.67	282377.72	8.43
256	553922.27	8.74	577951.13	8.58	316931.91	23.10
512	662368.79	15.83	763726.51	17.01	317668.32	42.61
1024	653733.97	54.83	740835.95	38.94	315535.24	80.03

Write Only 性能

Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
32	36840.88	5.37	43984.28	7.17	60851.38	4.10
64	62582.56	8.13	82554.92	6.55	110359.75	4.49
128	107054.05	9.56	114874.89	10.09	167415.76	5.99
256	155494.00	13.70	181982.10	12.52	209163.02	10.27
512	242458.53	17.32	253635.91	19.29	238568.50	18.28
1024	291343.40	31.94	292482.33	36.89	249176.87	37.56

Read Write 性能

Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
32	66669.18	11.45	72554.47	11.87	92995.95	7.84
64	124559.80	12.52	139369.33	11.65	162191.70	9.22
128	209150.84	15.27	247061.25	12.30	219285.86	13.70
256	309329.85	20.00	313660.08	23.95	246672.33	25.74
512	395940.95	33.12	497734.89	25.74	270444.49	57.87
1024	454400.54	64.47	547816.87	54.83	256076.76	121.08

BMSQL TPCC 测试

测试方案：

通过 OBD 部署 OceanBase 集群，ODP 和 TPC-C 单独部署在一台机器上, 防止客户端的压力不足成为性能瓶颈。
3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPC-C 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），两次测试分别设置租户的 Primary Zone 为 RANDOM 和 Zone1，RANDOM 表示新建表分区的 Leader 随机到这 3 台机器，Zone1 表示新建表分区的 Leader 集中在 Zone1 的 1 台机器上。

租户规格：

MAX_CPU = 26
MEMORY_SIZE = 70g

参数调优：

#obproxy
ALTER proxyconfig SET proxy_mem_limited='4G';
ALTER proxyconfig set enable_compression_protocol=false;

#sys
ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

软件版本：
mysql-connector-java-5.1.47
Benchmark SQL V5.0
测试配置：

warehouse = 1000
loadWorder=40
terminals=800
runMins=5
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4

测试结果：

测试类型	V4.1 RANDOM	V4.2 RANDOM	V4.2 Zone1
tpmC (NewOrders)	293350.85	289711.96	139886.99
tpmTOTAL	652025.02	644025.66	310953.51
Transaction Count	3260125	3221995	1555658

TPCH 测试

测试方案：

使用 OBD 部署 OceanBase 数据库集群。TPC-H 客户端需要部署在一台机器上, 作为客户端的压力机器。您无需部署 ODP，测试时直连任意一台机器即可。
3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPCH 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone为 RANDOM。先执行数据装载，然后多次顺序执行 22 个 SQL 后取均值。
测试数据量：100GB。

租户规格：

MAX_CPU = 26
MEMORY_SIZE = 70g

参数调优：

#sys
ALTER system flush plan cache GLOBAL;
ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

#测试租户
SET GLOBAL ob_sql_work_area_percentage = 80;
SET GLOBAL ob_query_timeout = 36000000000;
SET GLOBAL ob_trx_timeout = 36000000000;
SET GLOBAL max_allowed_packet = 67108864;
SET GLOBAL parallel_servers_target = 624;

测试结果：

Query	V4.1（s）	V4.2（s）
Q1	2.18	2.24
Q2	0.23	0.48
Q3	1.48	1.49
Q4	0.53	0.66
Q5	0.98	0.95
Q6	0.13	0.14
Q7	1.46	1.35
Q8	0.92	1.09
Q9	2.82	4.46
Q10	1.10	0.95
Q11	0.17	0.19
Q12	1.36	1.34
Q13	1.89	1.86
Q14	0.29	0.41
Q15	0.88	0.88
Q16	0.66	0.67
Q17	1.62	1.57
Q18	0.82	0.91
Q19	0.61	0.64
Q20	1.07	1.12
Q21	2.54	2.52
Q22	1.08	1.11
Total	24.82	27.03

TPC-DS 测试

测试方案：

使用 OBD 部署 OceanBase 数据库集群。客户端需要部署在一台机器上, 作为客户端的压力机器。您无需部署 ODP，测试时直连任意一台机器即可。
3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPCDS 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM。先执行数据装载，然后多次顺序执行 99 个 SQL 后取均值。
测试数据量：100GB。

租户信息：

MAX_CPU = 26
MEMORY_SIZE = 70g

参数调优：

#sys
ALTER system flush plan cache GLOBAL;
ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

#测试租户
SET GLOBAL ob_sql_work_area_percentage = 80;
SET GLOBAL ob_query_timeout = 36000000000;
SET GLOBAL ob_trx_timeout = 36000000000;
SET GLOBAL max_allowed_packet = 67108864;
SET GLOBAL parallel_servers_target = 624;

测试结果：

Query	V4.1（s）	V4.2（s）
Q1	0.63	0.64
Q2	3.46	1.17
Q3	0.16	0.17
Q4	9.43	9.76
Q5	1.63	1.71
Q6	0.37	0.42
Q7	0.28	0.31
Q8	0.39	0.26
Q9	1.89	1.90
Q10	0.50	0.51
Q11	5.79	6.02
Q12	0.28	0.23
Q13	2.04	0.57
Q14	11.38	11.22
Q15	0.23	0.23
Q16	0.92	0.95
Q17	0.52	0.46
Q18	0.32	0.37
Q19	0.17	0.28
Q20	0.19	0.19
Q21	0.29	0.31
Q22	1.11	1.23
Q23	14.20	14.55
Q24	1.56	1.41
Q25	0.62	0.49
Q26	0.21	0.22
Q27	0.35	0.42
Q28	7.44	6.58
Q29	0.64	0.53
Q30	0.27	0.31
Q31	0.62	0.67
Q32	0.11	0.11
Q33	0.77	0.55
Q34	0.37	0.56
Q35	0.87	0.90
Q36	0.31	0.32
Q37	0.42	0.46
Q38	1.49	1.60
Q39	2.31	0.85
Q40	0.16	0.17
Q41	0.18	0.08
Q42	0.11	0.13
Q43	0.64	0.65
Q44	0.45	0.49
Q45	0.39	0.32
Q46	0.81	0.65
Q47	1.16	1.21
Q48	0.61	0.66
Q49	0.86	0.92
Q50	0.81	0.68
Q51	2.82	2.83
Q52	0.11	0.12
Q53	0.24	0.25
Q54	1.05	1.04
Q55	0.11	0.11
Q56	1.01	0.56
Q57	0.79	0.80
Q58	0.60	0.65
Q59	13.64	3.11
Q60	1.13	0.69
Q61	0.30	0.33
Q62	0.40	0.42
Q63	0.23	0.24
Q64	1.84	1.89
Q65	2.70	2.77
Q66	0.46	0.49
Q67	16.12	9.59
Q68	0.67	0.48
Q69	0.44	0.46
Q70	1.18	1.36
Q71	0.54	0.54
Q72	1.47	1.34
Q73	0.31	0.41
Q74	6.36	4.36
Q75	2.26	2.55
Q76	0.49	0.50
Q77	0.71	0.74
Q78	3.64	3.46
Q79	0.65	0.70
Q80	1.78	3.45
Q81	0.30	0.26
Q82	0.67	0.79
Q83	0.69	0.76
Q84	0.19	0.20
Q85	0.84	0.92
Q86	0.36	0.33
Q87	1.59	1.70
Q88	0.65	0.85
Q89	0.30	0.32
Q90	0.19	0.47
Q91	0.13	0.16
Q92	0.10	0.10
Q93	0.75	0.76
Q94	0.62	0.65
Q95	6.37	6.36
Q96	0.38	0.44
Q97	0.93	0.94
Q98	0.30	0.30
Q99	0.70	0.80
Total Time	160.83	138.75

兼容性变更

产品行为变更

新增如下变更：

功能	变更版本	变更点说明
TableGroup	4.2	不再支持 TableGroup 上的分区属性，不再通过分区属性限制一个 Table Group 里面的表的分区方式，也不再支持 TableGroup 相关的分区管理操作； TableGroup 内分区的聚集和打散语义不再相同，V4.2.0 版本为 TableGroup 引入了 SHARDING 属性，用于控制 TableGroup 内表数据的聚集和打散关系。TableGroup SHARDING 属性有三种取值：NONE、PARTITION、ADAPTIVE。
Cap 类配置项	4.2	Cap 类配置项的默认单位是 Mb，常被用户误以为是 byte，导致设置的结果远超限制。为了消除不带单位更新配置项导致的非预期结果，在更新 Cap 类配置项时需要指定 Value 的单位，未带单位的更新行为会失败。

视图变更

新增如下变更：

视图	变更版本	变更类型	变更说明
CDB/DBA_OB_TABLEGROUPS	4.2	修改	分区属性字段将不再有含义，展示为 NULL。
CDB/DBA_OB_TABLEGROUP_PARTITIONS	4.2	废弃	视图将废弃，不再展示数据。
CDB/DBA_OB_TABLEGROUP_SUBPARTITIONS	4.2	废弃	视图将废弃，不再展示数据。
CDB/DBA_OB_BALANCE_JOBS	4.2	新增	展示租户下当前正在执行的负载均衡工作。租户下同一时间只有一个负载均衡工作（JOB），每个工作会生成多个负载均衡任务（TASK）。 CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_BALANCE_JOB_HISTORY	4.2	新增	展示租户下所有执行负载均衡工作的历史。 CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_BALANCE_TASKS	4.2	新增	展示租户下当前正在执行的负载均衡任务。同一时间可能有多个负载均衡任务正在执行，这些任务（TASK）都属于同一个负载均衡工作（JOB）。 CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_BALANCE_TASK_HISTORY	4.2	新增	展示租户下所有执行负载均衡任务的历史。 CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_TRANSFER_TASKS	4.2	新增	展示租户下当前正在执行的Transfer任务。 CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_TRANSFER_TASK_HISTORY	4.2	新增	展示租户下所有执行Transfer任务的历史。 CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_TABLE_LOCATIONS	4.2	修改	修改视图，新增列 DUPLICATE_SCOPE、OBJECT_ID、TABLEGROUP_NAME、TABLEGROUP_ID、SHARDING。用以更好地观察集群/租户的负载均衡状态。
DBA_OB_TENANTS	4.2	修改	修改视图，新增列 UNIT_NUM、COMPATIBLE。用以展示集群/租户下租户的 UNIT 数量。
[G]V$OB_THREAD	4.2	新增	记录全量线程的状态信息，每行表示一个线程。
[G]V$OB_LOCKS	4.2	新增	基于 Oracle 的 V$LOCK 视图实现 OceanBase 数据库自有锁视图 `[G]V$OB_LOCKS`。同时，在 Oracle 的锁视图的基础上增加 TR 类型的锁，用以描述“行锁”，即未发生转储前的锁。
[G]V$OB_ARBITRATION_SERVICE_STATUS	4.2	新增	展示 OceanBase 集群和仲裁服务之间的联通状态。
[G]V$OB_ARBITRATION_MEMBER_INFO	4.2	新增	展示本集群的仲裁成员信息。
[G]V$OB_OPT_STAT_GATHER_MONITOR	4.2	新增	查询统计信息收集任务实时状态。
DBA_OB_TASK_OPT_STAT_GATHER_HISTORY	4.2	新增	查询历史收集任务执行情况。
DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY	4.2	新增	查询表的历史收集执行情况。
[G]V$OB_UNITS	4.2	修改	新增列 ZONE_TYPE、REGION。
CDB/DBA_OB_DATA_DICTIONARY_IN_LOG	4.2	修改	记录数据字典在系统日志流中的位置范围，方便 CDC 消费数据字典。
[G]V$OB_LOCKS	4.2	新增	显示当前用户各表持锁或请求锁的情况。
CDB/DBA_OB_LOG_RESTORE_SOURCE	4.2	新增	展示物理恢复租户、备租户的日志恢复源。
V$OB_LS_LOG_RESTORE_STATUS	4.2	新增	展示日志流级别日志恢复状态。
V$OB_TIMESTAMP_SERVICE	4.2	新增	显示租户时钟服务的 GTS/STS 值、时钟服务所在的节点信息和时钟源类型。
[G]V$OB_PX_P2P_DATAHUB	4.2	新增	展示并行执行的数据传输操作的相关信息。
[G]V$SQL_JOIN_FILTER	4.2	新增	动态展示 Join Filter 执行相关信息。
DBA_OB_TABLE_STAT_STALE_INFO	4.2	新增	展示自上次收集统计信息以来每个表发生的 DDL 操作次数，以及当前统计信息是否已过期。
CDB/DBA/ALL_OB_EXTERNAL_TABLE_FILES	4.2	新增	展示当前租户下所有已创建的外表所对应的文件列表。
CDB/DBA_OB_ACCESS_POINT	4.2	新增	展示租户入口的 Server 列表。
[G]V$OB_SQL_PLAN	4.2	新增	显示用户通过执行 EXPLAIN PLAN 收集到的计划信息。
[G]V$OB_LOG_STAT	4.2	修改	新增列 ARBITRATION_MEMBER、DEGRADED_LIST、LEARNER_LIST。

系统变量变更

新增如下变更：

系统变量	变更版本	变更类型	变更说明
runtime_filter_type	4.2	新增	SESSION/GLOBAL 级别系统变量，设置租户级别的 Runtime Filter 类型, 包含 BLOOM_FILTER、RANGE、IN 三种类型, 若取值为空字符串，则表示关闭 Runtime Filter 功能。
runtime_filter_wait_time_ms	4.2	新增	SESSION/GLOBAL 级别系统变量，设置 runtime filter 的最大等待时间。默认10ms。
runtime_filter_max_in_num	4.2	新增	SESSION/GLOBAL 级别系统变量，设置 Runtime In Filter 中最大 NDV 个数。默认1024。
runtime_bloom_filter_max_size	4.2	新增	SESSION/GLOBAL 级别系统变量，设置 runtime bloom filter 的最大使用内存, 单位为字节。默认为 2 1024 1024 * 1024 (2G)。
optimizer_dynamic_sampling	4.2	新增	SESSION/GLOBAL 级别系统变量，用于控制动态采样的等级，目前仅支持 0 和 1，0 为关闭动态采样功能，1 为开启动态采样功能。默认为 1。
parallel_degree_policy	4.2	新增	SESSION/GLOBAL 级别系统变量，用于控制 SQL 并行执行的并行度选择策略。默认为 MANUAL，表示启用 Auto DOP。
parallel_degree_limit	4.2	新增	SESSION/GLOBAL 级别系统变量，使用 Auto DOP 策略时，限制优化器选择的并行度上限值。默认值为 0，此时不对计算得到的并行度进行限制。
parallel_min_scan_time_threshold	4.2	新增	SESSION/GLOBAL 级别系统变量，使用 Auto DOP 策略计算基表并行度时，基表扫描估计执行时间超过 `parallel_min_scan_time_threshold` 设定值时，增加并行度开启并行。默认值 1000ms。
secure_file_priv	4.2	修改	GLOBAL 级别系统变量，安全原因，修改为限制只能使用通过本地 Unix Socket 连接的 Client 执行修改该全局变量的 SQL 语句。

配置项变更

配置项	变更版本	变更类型	变更说明
enable_rebalance	4.2	修改	调整为租户级配置项。系统租户下控制是否进行租户间均衡；普通租户下控制是否进行租户内均衡。
balancer_idle_time	4.2	修改	调整为租户级配置项。系统租户下表示容灾线程和均衡线程的时间间隔；普通租户下租户下表示日志流均衡线程的时间间隔。
partition_balance_schedule_interval	4.2	新增	租户级配置项，用于设置分区均衡调度周期。
log_disk_throttling_percentage	4.2	新增	租户级配置项，表示触发日志写入限速的不可回收日志盘空间占比。当日志盘不可回收空间比例达到 `log_disk_throttling_percentage/100` 时，即触发日志写入限速；当日志盘不可回收空间比例回落到 `log_disk_throttling_percentage/100` 以下后，日志写入限速会停止。当该配置项取值为 100 时，表示关闭日志写入限速。默认值为 60。
log_disk_throttling_maximum_duration	4.2	新增	租户级配置项，表示触发日志写入限速后，日志盘预期最大可用时间，即剩余可用日志盘空间预计在 `log_disk_throttling_maximum_duration` 后才会被消耗完。设置的越大，则预期日志限速支撑的时间越长，限速的力度越大。默认值为 2h。
_optimizer_ads_time_limit	4.2	新增	租户级隐藏配置项，控制优化器动态采样的采样时间上限，单位秒。默认为 10。
datafile_maxsize	4.2	新增	集群级配置项，控制磁盘数据文件自动扩容的上限值。默认为 0。
datafile_next	4.2	新增	集群级配置项，控制磁盘数据文件自动扩容的步长。默认为 0。
_datafile_usage_upper_bound_percentage	4.2	新增	集群级配置项，控制磁盘文件自动扩容的触发时机，当数据文件使用率超过该值则触发扩容。默认为 90。
standby_db_fetch_log_rpc_timeout	4.2	新增	租户级配置项，用于设置备库拉取日志 RPC 超时时间，以控制备库日志传输服务检测主库某台 Server 不可用并切换到其他 Server。默认为 15s。
location_refresh_thread_count	4.2	修改	默认值由 4 调整为 2。
enable_record_trace_id	4.2	修改	默认值由 True 调整为 False。
plan_cache_evict_interval	4.2	修改	默认值由 1s 调整到 5s。
devname	4.2	修改	动态生效调整为只读。
local_ip	4.2	新增	集群级配置项，表示安装 OBServer 机器的 IP 地址。只读。
observer_id	4.2	新增	集群级配置项，用于集群中 RS 分配给 OBServer 节点的唯一标识。只读。
standby_fetch_log_bandwidth_limit	4.2	新增	集群级配置项，备库集群中的所有 Server 从主库同步日志的流量总和占用的最大带宽，默认值为 0 ，代表不对流量进行限制。
ls_gc_delay_time	4.2	新增	租户级配置项，用于配置物理备库场景下，主租户日志流延迟删除的时间。
archive_lag_target	4.2	新增	租户级配置项，用于控制租户日志归档延迟的时间。
standby_db_preferred_upstream_log_region	4.2	新增	租户级配置项，用于配置物理备库场景下，备租户同步上游日志的首选 Region。
storage_meta_cache_priority	4.2	新增	集群级配置项，用于控制 kvcache 中存储 Meta Cache 的优先级。
range_optimizer_max_mem_size	4.2	新增	租户级配置项，用于限制 Query Range 模块使用的内存。
rootservice_memory_limit	4.2	废弃	集群级配置项，用于设置 Root Service 的最大内存容量限制。
trace_log_sampling_interval	4.2	废弃	集群级配置项，用于设置定期打印跟踪日志信息的时间。
tenant_cpu_variation_per_server	4.2	废弃	集群级配置项，用于设置租户多个 UNIT 之间 CPU 配额调度允许的偏差。
token_reserved_percentage	4.2	废弃	集群级配置项，用于设置每次预留多少比例的空闲 token 数给租户。
global_write_halt_residual_memory	4.2	废弃	集群级配置项，用于设置触发暂停普通租户写入（sys 租户不受影响）的全局剩余内存阈值。
plan_cache_high_watermark	4.2	废弃	集群级配置项，用于设置执行计划缓存占用内存的阈值，如果超过该阈值时将触发自动淘汰。
plan_cache_low_watermark	4.2	废弃	集群级配置项，用于设置执行计划缓存占用内存的阈值，如果低于该阈值时将停止淘汰。
max_px_worker_count	4.2	废弃	集群级配置项，用于设置 SQL 并行查询引擎使用的最大线程数。
io_category_config	4.2	废弃	组户级配置项，用于配置各类别 I/O 请求的百分比。

函数变更

函数	变更版本	变更类型	变更说明
`RANDOM([N])`	4.2	新增	随机生成一个 64 位整数。
`RANDSTR(N, gen)`	4.2	新增	随机生成长度为 N 的字符串，`gen` 为随机方法。
`NORMAL(<mean> , <stddev> , <gen>)`	4.2	新增	返回一个符合正态分布（`normal distribution`，又称高斯分布）的浮点数。
`UNIFORM(<min> , <max> , <gen>)`	4.2	新增	返回一个符合均匀分布（`uniform distribution`）的整数或浮点数。
`ZIPF(<s> , <N> , <gen>)`	4.2	新增	返回一个符合齐夫分布（`zipf distribution`）的整数。

周边配套

OceanBase 数据库 V4.2.0_CE 版本推荐使用的平台工具版本如下。

组件	版本	备注
ODP	ODP V4.2.0	-
OCP	V4.0.3_CE	租户主备库功能暂不支持
OBD	OBD V2.2.0	-
All in One	V4.2.0_CE_BETA	-
ODC	ODC V4.1.3 BP3	整体适配是在 ODC V4.2.1版本，预计是8月底发布
OBCDC	OBCDC V4.2.0	-
OMS	V4.1.1_CE	-
OBClient	OBClient V2.2.2	-
LibOBClient	LibOBClient V2.2.2	-

升级说明

支持 OceanBase 数据库 V4.1.0_CE 版本在线升级到 OceanBase 数据库 V4.2.0_CE_Beta 版本。
不支持从 OceanBase 数据库 V3.x 版本在线升级到 OceanBase 数据库 V4.2.0_CE 版本。
支持通过 OMS 将 OceanBase 数据库 V3.x 版本数据使用逻辑迁移升级到 OceanBase 数据库 V4.2.0_CE 版本。

注意事项

该版本不建议打开 RPC SSL，相关问题会在后续版本优化。
对于 GB18030 到 GB18030-2022 字符集的升级，需要进行逻辑升级。

v4.2.0_CE_BETA

V4.2.0_CE_Beta

版本信息

版本定位

关键特性说明

MySQL兼容

性能提升

统计信息强化

动态采样

Runtime Filter

4C 小规格性能优化

快速随机数据生成

OLAP 能力

只读外表

扩展性增强

Transfer 和负载均衡

复制表

高可用增强

物理备库

资源使用优化

磁盘数据文件按需扩展

易用性提升

Auto DOP

全链路诊断能力增强

逻辑计划管理

国家标准

GB18030-2022 字符集

产品形态

单机主备库

只读副本（R 副本）

性能报告

SYSBENCH OLTP负载测试

BMSQL TPCC 测试

TPCH 测试

TPC-DS 测试

兼容性变更

产品行为变更

视图变更

系统变量变更

配置项变更

函数变更

周边配套

升级说明

注意事项

Uh oh!