版本信息

版本定位

V4.2.3_CE_BETA 为 V4.2.x_CE 系列最新版本，支持了一系列 MySQL 兼容特性，如角色、列级权限、Union Distinct RCTE 及大量小功能兼容。在多个场景优化了系统性能，如优化多模类型读写计算和 OBKV 处理效率，扩展 Batch DML 的并行执行能力，提升备份/网络备库性能，解决自增列/Sequence 在 Order 模式下的性能问题等。同时，备份恢复扩展支持了 S3 及兼容 S3 协议的对象存储（如：OBS，GCS）作为备份目的端。在资源优化方面，进行了一系列优化包括 DDL 临时结果空间优化、旁路导入能力提升和全局前后台 CPU 资源隔离等。新版本也实现了多个业务期待的易用性功能，如用于日志分析和误操作识别的 ObLogMiner 功能，应对 Buffer 表性能问题的合并策略选择，提供模糊绑定计划和限流方式的 Format Outline，用于识别无用索引的索引使用监控特性，提供更高可读性的面向数据库管理员的 alert.log 系统日志，增加日志流副本管理的用户命令，提供物理恢复进度展示能力。更详细的 PX 诊断数据以及 ASH Report 的节点级分析等，有效提高系统易用性。

推荐用于测试，暂不建议用于生产。

关键特性说明

内核增强

• 查询解析能力增强

  SQL 中存在个数特别多的 INLIST 、AND/OR、UNION 时，往往会产生超深语法树解析，进而造成内存消耗过大、栈不足、耗时过长的问题。新版本重写这些极端场景的查询解析实现，降低了解析阶段资源消耗，增强了极端 SQL 执行的稳定性，同时提升了 SQL 解析性能。例如 select sum(c1) from t1 where c1 in (1, 2, 3, ...N) 中 N = 20 万的查询场景，V4.2.3_CE 版本的解析性能相对 V4.2.2_CE 版本可以提升 20%~30%。

• 查询改写能力增强

  V4.2.3_CE 版本优化器从多个方面优化了查询改写逻辑，例如：

  • 表达式规范化强化：历史版本在 Resolver 解析阶段会对多种表达式进行规范化（Canonicalize），例如将 A and (A or B) 改写为 A ，但未覆盖到 SQL 改写阶段新产生的不规范表达式。新版本引入改写阶段的表达式规范化流程，确保将表达式改写到最简化状态。

  • 条件聚合函数改写：我们将形如 select c1, sum(case when c2 = 0 then c3 else 0 end),sum(case when...)...,... from t1 group by c1, 聚合目标不是某个确定的表达式，而是在运行时根据分支选择条件的判定结果选择出的表达式，称为条件聚合函数。新版本支持了条件聚合函数改写，支持将聚合函数压入每个分支的选择目标上，减少 case when 表达式和聚合函数的计算次数，提升相关场景的执行性能。

  • 多 Min/Max 改写：在 scalar group by 中，若查询中的聚合函数只有 Min/Max，且 Min/Max 的列上有索引，可以将其改写成 order by xxx limit 1，利用索引序消除 Order By 并将 Limit 1 下推到 TABLE SCAN 上，从而减少对数据的读取和排序。对于 SQL 中有多个 Min/Max 存在的场景，历史版本采取了全表扫描方案，新版本考虑将多个 Min/Max 改写成多个子查询，每个子查询都利用索引直接获取到最大值或最小值，以此来避免全表扫描和排序，优化查询性能。

  • 常量 UNION 改写 Values Table：业务较常使用多个 UNION ALL 的组合形式表示一个常量表，在子查询数量过多时，会有较多 CPU 和内存消耗。新版本对常量类型的 UNION ALL/UNION 改写成对 Values Table 的查询，显著降低硬解析阶段的资源消耗。

  • SEMI JOIN 拆分优化：EXISTS 或 IN 子查询中存在多表关联且没有连接条件时，执行计划可能会出现开销较大的笛卡尔积。新版本支持对没有连接条件的表做 SEMI JOIN 拆分改写，避免笛卡尔积开销。

• 计划选择优化

  V4.2.2_CE 版本实现了新版 Query Range 抽取逻辑，扩展了谓词下压场景，使向量形式谓词的 Range 抽取更加精准，也解决了历史版本 Query Range 的一些内存放大的场景问题。V4.2.3_CE 版本在此基础上修改了 not in 表达式生成 Query Range 的方式，优化了 Range 抽取性能；支持 Range Graph 裁剪，减少最终 Query Range 的抽取数量，降低内存消耗；扩展 INDEX Hint，如指定 /*+index(t1 k1 1)*/ 时，限制只对 k1 索引的第 1 列进行 Query Range 抽取。同时，新版本也支持了 Interesting Ordering 索引路径按规则裁剪，Limit 重计算等策略优化，解决 order by limit 场景因计划选择不优导致的性能问题。

• 自适应代价模型

  OceanBase 数据库历史版本代价模型是使用内部机器测算的常量参数来代表硬件系统统计信息，通过一系列公式与常量参数来描述每个算子的执行开销。而真实的业务场景中，不同硬件环境可能具备不同的 CPU 时钟频率、不同的顺序读或随机读的速度、不同的网卡带宽等，可能存在代价估算偏差，这些偏差会使得优化器无法在不同的业务环境总是生成最优计划。新版本优化代价模型实现，支持通过 DBMS_STATS 包来收集或设置系统统计信息系数，以达到代价模型自适应硬件的目的。同时也提供了 DBA_OB_AUX_STATISTICS 视图，用于展示当前租户的系统统计信息系数。

• 复制表属性变更

  复制表是 OceanBase 数据库 V4.2.0 版本开始支持的一种特殊表。这种表可以在任意一个“健康”的副本上读取到数据的最新修改。如果需要转换复制表为普通表，或转换普通表为复制表，V4.2.3_CE 版本之前需要重新建表导数，操作较耗时和复杂。新版本提供复制表属性变更功能，可通过 ALTER TABLE 命令实现表属性转换，降低用户操作成本。

• 产品行为兼容版本控制

  为了减少因为新版本行为变更导致升级后某些老版本特性使用报错的问题，OceanBase 数据库 V4.2.3_CE 版本新增产品行为兼容版本控制功能，支持通过 ob_compatibility_version、ob_security_version 系统变量，分别控制普通行为变更（不报错 -> 报错场景）、安全行为变更（有权限 -> 无权限）是否生效，一个租户中的兼容功能或安全功能按照哪个 OceanBase 版本来兼容，取值范围为 "4.2.3.0" 等发行版本。例如一个功能在 V4.2.4 版本发生了产品行为变更，当变量取值为 4.2.3.0 时，使用旧行为；取值为 4.2.4.0 时，使用新行为。通常升级场景不会自动推高该版本号，需要新版本行为时，请升级后，了解新版本行为并测试后，修改为和当前版本一致的版本号。该方案仅用于控制未来新增的产品行为变更，无法控制已经发版的存量产品行为变更。

  V4.2.3_CE 版本通过 ob_compatibility_version 控制的产品行为有：

  • ob_compatibility_control = MYSQL5.7 时，REPLACE('abd', '', null) 行为由兼容 MySQL 8.0 修改为兼容 MySQL 5.7。
  • UPDATE/DELETE statement 在 Limit 中禁用 Offset。
  • 当投影项是单独的一个 null 值的时候，返回的表头会被修改为 NULL。
  • 限制用户变量最长 64 字符。

  通过 ob_security_version 控制的产品行为有：

  • Outline、Sequence 增加权限管控。
  • CREATE TABLESPACE 权限。

MySQL 兼容

• 角色管理

  OceanBase 数据库 V4.2.3_CE 版本兼容了 MySQL 8.0 的角色管理功能，通过角色来管理维护一组权限，可以更方便地对某一类用户进行授权和回收。与普通用户类似，角色可以被授予或回收权限，也可以被授予或回收其他角色。用户可以被授予多个角色，但仅能使用激活状态角色中的权限。有关角色管理的更多信息，参见 角色管理。

• 列级权限

  V4.2.3_CE 版本新增 MySQL 列级权限功能，可以用于控制用户是否有权限对某张表的某几列进行 SELECT、INSERT 或 UPDATE。

• Outline、Sequence 权限管控

  历史版本缺少对创建维护 Outline、Sequence 的权限管控，新版本复用 MySQL CREATE、ALTER、DROP 权限，控制 Outline、Sequence 的创建、修改和删除。

• 自增列切主跳变优化

  OceanBase 数据库在 V4.x 版本支持了创建 ORDER 模式的自增列，更好地兼容了 MySQL 自增列行为。但是 V4.2.3_CE 之前版本在出现切主时，仍会造成自增列跳变。考虑到很多切主场景是用户主动发起的流程，并非异常场景，所以新版本优化为主动切主时仍保持自增列连续性，降低自增列跳变概率。有关自增列的更多信息，参见 自增列。

• 自增列改小

  V4.2.3_CE 之前的版本，仅支持通过 ALTER TABLE 将 AUTO_INCREMENT 值改大，不支持改小，行为上和 MySQL 不完全兼容。新版本补充支持了 AUTO_INCREMENT 值改小的功能，指定新值大于自增列已存在的最大值时，可以设置成功且生效；指定新值小于或等于自增列已存在的最大值时，也可以设置成功，但 AUTO_INCREMENT 会自动调整为自增列已存在的最大值的下一个值。

• Union Distinct RCTE

  MySQL 8.0 支持了 CTE 的 Recursive Union All 及 Recursive Union Distinct 功能。OceanBase 数据库从 V3.2.3 版本开始支持 MySQL 模式的 Recursive Union，但仅支持 Recursive Union All，V4.2.3_CE 版本扩展兼容了的 MySQL Recursive Union Distinct 功能，保证输出数据的唯一性。同时，新版本还加强了 Recursive Union All 功能，支持可使用内存不足时进行数据落盘。有关 Union Distinct RCTE 的更多信息，参见 通用表表达式。

• 区分 MySQL 5.7/8.0 兼容版本

  MySQL 5.7 与 8.0 在部分场景下存在产品行为冲突，如 replace('a','',null) 在两个版本的输出结果不同。OceanBase 数据库 V4.2.3_CE 版本新增租户级初始化变量 ob_compatibility_control，用于在创建租户时指定存在产品行为冲突的情况是兼容 MySQL 5.7 版本，还是 8.0 版本。租户创建后不可修改，两种模式下均可使用不存在行为冲突的 MySQL 5.7/8.0 的特性超集。

• 语法/变量/视图支持

  为了支持 MySQL 生态的各类工具或框架无需修改即可平滑迁移到 OceanBase 数据库，V4.2.3_CE 及之后版本会针对 MySQL 5.7 全量功能，对 OceanBase 数据库还未兼容细节的部分、不适用的能力，逐步进行兼容或 Mock 处理。

  V4.2.3_CE 版本支持的兼容能力如下：

  • 支持数据类型 SERIAL。
  • [MySQL 8.0] 支持创建触发器时指定 IF NOT EXISTS 语法。
  • SQL 语句中支持使用 \N 代表 NULL。
  • 兼容 MySQL，update/delete ... limit 语句禁用 offset 子句。
  • 兼容 MySQL 5.7 password 函数。
  • 兼容 MySQL DROP USER IF EXISTS 语法。
  • 兼容 MySQL，用户变量标识符长度限制 64 个字符。
  • 兼容 CREATE TABLE ... [IGNORE | REPLACE] SELECT statement。
  • SELECT 语句支持 STRAIGHT_JOIN 。
  • 支持 MySQL CREATE TABLESPACE 权限。
  • 支持授予、回收、查看 MySQL SHUTDOWN、RELOAD 权限，实际不生效。
  • DML 忽略 PRIORITY 不报错，不生效。
  • INSERT 忽略 LOW_PRIORITY、 HIGH_PRIORITY 不报错，不生效。
  • UPDATE 忽略 LOW_PRIORITY 不报错，不生效。
  • DELETE 忽略 LOW_PRIORITY、QUICK 不报错，不生效。
  • REPLACE 忽略 LOW_PRIORITY 不报错，不生效。
  • SELECT 忽略 SQL_SMALL_RESULT、SQL_BIG_RESULT、SQL_BUFFER_RESULT、HIGH_PRIORITY 不报错，不生效。
  • 兼容 MySQL 5.7，忽略降序索引语法不报错，不生效。
  • 兼容 MySQL 5.7，忽略 CREATE TABLE 中 Column 后的 reference_definition 语法，不报错，不生效。
  • 忽略建表建索引指定的 KEY_BLOCK_SIZE option，不报错，不生效。
  • FLUSH PRIVILEGES：语法不报错，实际不适用。
  • Show Profile/Profiles：语法不报错，实际不生效。
  • SHOW FUNCTION/PROCEDURE CODE：语法不报错，实际功能未支持。
  • 支持 INFORMATION_SCHEMA.PROFILING 表结构。
  • 新增 MySQL 变量（debug、debug_sync、innodb_change_buffering_debug、innodb_compress_debug、innodb_disable_resize_buffer_pool_debug、innodb_fil_make_page_dirty_debug、innodb_limit_optimistic_insert_debug、innodb_merge_threshold_set_all_debug、innodb_saved_page_number_debug、innodb_trx_purge_view_update_only_debug、innodb_trx_rseg_n_slots_debug、stored_program_cache、profiling、profiling_history_size、innodb_stats_persistent）。变量不产生实际效果，可查询可设置。设置后不会报错，也不会生效，产生 Warning。
  • 兼容 MySQL 5.7 通信协议 COM_PROCESS_INFO、COM_PROCESS_KILL；支持通信协议 COM_REFRESH、COM_DEBUG，实际不生效。

多模特性

• MySQL GIS

  OceanBase 数据库 V4.1.0 版本开始支持 GIS 数据类型及部分空间对象相关的表达式，后续逐渐增加了空间数据存储和计算分析的能力。新版本 MySQL 模式下扩展支持 PostGis_ST_GeoHash 表达式，用于计算 Geometry 的 Geohash 编码；扩展 PostGis_ST_MAKEPOINT 表达式，用于根据坐标创建 2D 和 3D 的 Geometry Point；新增支持 MySQL ST_ASGEOJSON 表达式，用于将 Geometry（WKB）按一定的格式转成 Json（Binary）。

• JSON/XML/GIS 内存优化

  新版本对 JSON 表达式执行过程中内存占用进行了优化，对 JSON 类型进行查询操作（JSON_KEYS、JSON_LENGTH、JSON_SEARCH 等）时，内存占用减少至 1 倍；对 JSON 类型进行输出操作（JSON_PRETTY、JSON_UNQUOTE 等）时，内存占用减少至 3 倍左右。在插入更新 XML 和输出 XML 的场景也进行了内存优化。输出 XML 操作（GetClobVal、XmlCast 等）内存占用减少到 2~3 倍左右；插入更新 XML （UpdateXml、InsertChildXml 等）时减少了不必要的解析。

  新版本同时对 GIS 类型数据输入、输出以及部分查询场景进行了内存优化。GIS 输入（st_geomfromtext/st_geomfromwkb/st_geogfromtext/geometrycollection 等）内存占用减少到 3 倍左右；GIS 输出（st_astext/st_aswkb 等）内存占用减少到 1 倍左右；查询场景（st_crosses/st_overlaps/_st_touches 等空间关系查询表达式、st_geometrytype/st_iscollection 等 GIS 属性获取表达式）也明显降低了内存放大程度。

• GIS 空间关系计算性能优化

  新版本优化了 ST_INTERSECTS/ST_CONTAINS/_ST_COVERS/ST_WITHIN 等空间关系计算表达式的计算性能。

  • 在全量查询窗查询场景，Point 的 st_intersects 与 PG 持平，且略优于 PG；其余测试场景的平均 RT 均不到 PG 的一半，其中 Linestring 的 Intersect 用时只有 PG 的 1/5 ，相比 OceanBase 数据库历史版本均有数量级的提升。

  • 在大查询窗场景，所有场景的平均 RT 均明显优于 PG，其中 Linestring 的 Intersect 用时仅有 PG 的 1/7，且相比 OceanBase 数据库历史版本均有数量级的提升。

  • 在小查询窗场景，Contain 计算会优于 PG，其中 Point 的 Contain 用时是 PG 的 1/4 左右，Linestring Contain 是 PG 的 80%。但 Intersect 的计算性能在 Linestring 场景仅与 PG 持平，在 POINT 场景用时是 PG 的 2 倍左右。

  有关空间函数的更多信息，参见 空间函数。

• OUTROW 存储的 LOB 读写性能优化

  V4.2.3_CE 版本重点对 OUTROW 存储的 LOB 进行了性能优化。

  • Table Scan 场景，相对历史版本，新版本中小 LOB 性能可以提升近 10 倍，大 LOB 可以提升至少 2 倍。但该场景相对 INROW 仍然慢一些。
  • Point Select 场景，新版本小 LOB (8K 以下)，OUTROW 的 QPS 比 INROW 低 20% 以内，中等以上大小的 LOB（32K 以上），OUTROW 的 QPS 比 INROW 低 5% 左右。在 LOB 不参与计算的场景，LOB OUTROW 存储对查询性能会更优。
  • Point Update 场景，相对历史版本，新版本 OUTROW 性能平均提升 2 倍。

  有关 OUTROW 存储的 LOB 的更多信息，参见 lob_enable_block_cache_threshold。

OBKV 增强

• OBKV 全局索引

  V4.1.0 版本开始，OBKV 支持了本地索引。新版本增加支持 OBKV 的全局索引功能，Insert、Update、Delete、insert_or_update、Replace、Increment/Append 等 DML 操作均适用于全局索引表，并支持了 Query 、异步 Query 指定全局索引查询。

• OBKV 性能优化

  OBKV 是一款集成在 OceanBase 数据库内部的低时延、高吞吐的 KV 存储类产品，在不需要通过 SQL 进行复杂逻辑处理的场景，可以跳过 SQL 模块直接调用存储接口，以获得极致性能。通过业务及内部端到端的测试分析，发现历史版本 KV 模型层性能开销还有进一步降低空间。因此新版本在以下多个场景，进行了性能优化：

  • 新增 Put 功能：Put 用于覆盖写场景，覆盖写跳过了主键冲突检查路径，强制覆盖旧记录。

  • 支持组提交：组提交是指服务端主动攒批，执行批量操作的功能。开启组提交后，服务端会将 Put 或 Get 操作按照执行计划分组，并根据负载情况自动调节组大小，按组执行。用户可通过租户级配置项 enable_kv_group_commit 开启组提交，开启后预期能够在不对 RT 造成明显影响情况下，提高 30%~50% 的 OPS。

  • 优化 Batch 批处理：OBKV 的批操作接口避免了单操作接口中每次事务开启关闭的耗时，在一定程度上提高了操作效率。但每个操作依然需要构造算子、打开算子、提交 DAS 任务、关闭算子和算子析构等步骤，存在一定的执行时间损耗。为了进一步提高批操作接口的执行效率，新版本在算子级别实现了多操作的批处理，减少 n-1 次的算子构造析构和 DAS 任务开销，有效提升整体性能。

  • 优化 Schema 获取逻辑：内部进行 Schema 获取的操作调整为语句级别，仅在语句执行时获取一次 Simple Schema，避免频繁获取 Schema 带来的性能损耗。同时将 Schema 的一些高频获取信息如 table_id、column_id 等缓存到计划中，实现了轻量级的 KV Schema Cache。

  • Batch 只返回一个结果：Multi Set 场景下，历史版本针对每个操作都返回了一个结果，新版本在设置 batchOps.setAtomicOperation(true) 和 batchOps.setReturnOneResult(true) 后，Multi Insert/Multi Put/Multi Delete 操作优化为只返回一个成功或者失败的结果，缩短交互周期。

性能提升

• DML 性能优化

  OceanBase 数据库已经支持通过 PDML 的并行执行机制来提高对大型表和索引执行插入、更新、删除等操作的性能。但是仍然存在部分场景是 PDML 暂未覆盖的，如 replace into ...、insert ... on duplicate key、insert all ...、merge into ... 更新主键、Insert 包含自增列、多表 Update 等。以上场景在之前版本会使用单线程写入方式，在数据量较大时响应时间较长，影响客户体验。为了解决大数据量的这些场景的性能瓶颈，V4.2.3_CE 版本新增支持 DAS 层并发写入能力，通过类似 PDML 的并发控制机制，显著提升 DML 执行性能。更多信息，参见 与并行执行相关的 Hint。

• 备份性能优化

  OceanBase 数据库备份过程中通过连续性校验确保基线版本大于转储版本以保证数据完整，但连续性检查涉及读取备份介质上的数据并执行带锁操作，影响了备份性能。新版本优化了备份过程中连续性校验操作的性能开销，支持通过 ha_low_thread_score 控制备份使用的线程数， 有效提高备份性能。更多信息，参见 数据备份。

• 网络备库性能优化

  V4.2.3_CE 版本优化了 RPC 及网络框架，降低了主备库之间的日志传输耗时；同时优化了备库受控拉日志流程，减少了备租户拉日志受控的频率，提高了主备之间的日志同步性能。

• 存储过程 DDL 执行编译结果缓存和落盘

  V4.2.2_CE 版本新增执行期存储过程编译落盘功能，解决了执行期存储过程获取 PL Cache 缓存失败，从而重编译引起的性能问题。但是存储过程自身做过 DDL 变更后，后续执行存储过程依旧需要重新编译，这个场景依然存在性能优化空间。V4.2.3_CE 版本补充支持存储过程 DDL 执行成功后将编译结果缓存到 PL Cache 并落盘的行为，后续执行存储过程时，提升直接命中 PL Cache 缓存的概率，进一步提高存储过程执行性能。

• 并行 DDL 扩展

  并行 DDL 与串行 DDL 互斥，在并行 DDL 与串行 DDL 交替执行时性能不优。随着版本演进，OceanBase 数据库也在不断扩展允许并行执行的 DDL 类型。V4.1.0 版本实现了并行 DDL 框架，并支持了 TRUNCATE 语句的并行执行；V4.2.1 版本支持了并行 CREATE TABLE；V4.2.2_CE 版本支持了并行 COMMENT 与并行 CREATE INDEX。在此基础上，V4.2.3_CE 版本扩展支持并行 CREATE VIEW，进一步提升 OMS 的结构迁移速度。

• 自增列 Order 模式性能优化

  自增列 Order 模式下，需要保持数据插入的连续性。为了保证分布式架构下自增列的有序，在自增列 INSERT 时会将该值持久化到内部表，高并发情况下，响应时间会比较长。V4.2.3_CE 对该场景做了优化，通过 Cache Size 预取有效降低内部表访问次数，从而显著提升性能。

• Sequence Order 模式性能优化

  OceanBase 数据库已支持指定 order + cache 属性来创建全局连续生成的序列，但早期的实现中会忽略 Cache 属性，等同于 order + nocache，在高并发场景会有明显性能问题。V4.2.3_CE 版本对该场景进行了优化，通过选取中心节点来支持 order + cache 生成连续序列，真正意义上实现 Cache 属性，显著提升高并发场景执行性能。

• Show Table Status 性能优化

  历史版本 show table status from ... like ... 场景性能较差，未利用 table_name 相关索引。新版本针对存在单表过滤条件的场景，显著提升查询性能。

• CREATE 语句支持 HINT

  在 V4.2.3_CE 版本中，新增对 CREATE TABLE 语句的 Hint 支持 /*+ parallel(N) */ 类型。该 Hint 适用于 CREATE TABLE ... AS SELECT ... 的场景，并可以控制在表创建时数据查询和写入操作的并行度。

资源优化

• CLOG 存储压缩

  随着越来越多 AP、HBASE 场景的替换需求出现，高写入场景可能会导致 CLOG 日志盘吞吐达到上限，需要通过扩容来解决资源问题。但可能集群其他类资源是未达到瓶颈的，整体扩容导致业务成本升高，资源过度浪费。为了解决这一问题，OceanBase 数据库 V4.2.3_CE 版本新增 CLOG 日志存储压缩功能，通过将事务提交的日志进行压缩，间接提高日志盘吞吐能力，提升日志盘可容纳的事务日志总量。更多信息，参见 log_storage_compress_all 和 log_storage_compress_func。

• OBServer 到 ODP 的链路压缩功能

  实际业务场景中，存在应用和数据库服务跨城部署的情况，距离较远、带宽有限，但仍然有大数据量读写的需求。为了降低大数据量传输带来的带宽消耗，该版本支持了 OBServer 到 ODP 的链路压缩功能，需配合 ODP V4.2.3_CE 或以上版本开启使用。

• DDL 临时结果空间优化

  在 DDL 过程中，常常会将临时结果暂存到物化结构中。在创建索引时，需要对数据表进行扫描并将数据插入到索引表中，此过程中可能需要对扫描出来的数据进行排序。如果内存空间不足，就会将当前内存中的数据暂存到物化结构中，以释放内存供后续的扫描使用。最后，对这些暂存在物化结构中的数据进行归并排序。

  针对这些问题，新版本 DDL 处理流程对数据流进行了优化。首先，它剔除了不必要的冗余结构，简化了数据流；其次，它引入了对临时结果落盘的编码压缩功能。这些改进为两个场景都带来了好处：它们显著降低了 DDL 操作期间临时结果对磁盘空间的占用，从而更加高效地利用存储资源。

• 旁路导入优化

  • 支持临时文件压缩：旁路导入过程中会产生临时文件，当导入的数据量比较大时，临时文件占用的磁盘空间比较大，需要关注磁盘的占用空间，避免旁路导入产生的临时文件将磁盘空间打爆，当旁路导入的 并发度 >= 8 时，系统会对产生临时文件做压缩，减少临时文件的空间占用。
  • 支持通配符方式多文件导入：在旁路导入过程中，新增了对通配符方式的多文件导入的支持。可以使用通配符 * 和 ? 来同时导入匹配特定模式的多个文件，从而提高导入效率和便利性。

  有关旁路导入的更多信息，参见 旁路导入。

• 全局 CPU 前后台任务隔离

  在高性能计算环境中，资源的合理分配与隔离对于确保系统稳定性和提升效率具有决定性作用。有效的资源隔离策略可以预防任务间的资源争夺和相互干扰，从而提升资源利用效率和整体服务质量。目前，OceanBase 数据库已实现了通过租户 Unit 规格来配置租户间的资源隔离，通过 DBMS_RESOURCE_MANAGER 系统包来配置租户内的资源隔离，涵盖 CPU 和 IO 两大重要资源。但对于不希望后台任务对前台请求造成严重 CPU 竞争的业务，在全局层面上对后台任务进行隔离是一个更好的选择。OceanBase 数据库 V4.2.3 版本支持了全局 CPU 前后台任务隔离能力，可以在整体层面上限制后台任务的可用资源，相对租户内使用 DBMS_RESOURCE_MANAGER 单独配置更加方便易用。有关全局 CPU 前后台任务隔离的更多信息，参见 配置 cgroup。

• 分区均衡策略优化

  OceanBase 数据库 V4.2.0 版本开始支持分区均衡功能，但在部分场景下还存在不完全均衡的问题。V4.2.3_CE 版本优化了分区均衡策略，在建分区表时支持了连续分区打散；当用户表存在 Longtext/Lob 列、局部索引时，分区磁盘均衡时也会计算关联表，使得磁盘使用更加均衡。

• 系统日志压缩

  业务流量过大时，系统日志刷新的会比较快，保留时间较短可能影响问题排查。新版本增加系统日志压缩功能，支持对 observer.log、rootservice.log、election.log、trace.log 等日志文件，每类超过 syslog_file_uncompressed_count 个数时，采用 syslog_compress_func 设置的压缩方法，对最早日志进行压缩。当日志使用总空间接近 syslog_disk_size 设置的磁盘空间上限时，开始删除最早生成的日志文件，回收空间。磁盘空间不变的情况下，开启 zstd 压缩后，预计可以存储不开启压缩时 20 倍的日志量。更多信息，参见 日志压缩与解压。

可靠性提升

• 迁移复制源端选择优化

  历史版本选择迁移复制的源端时没有优先考虑同 Zone、同 IDC (同机房)、同 Region (同城)的副本，可能出现远距离迁移复制性能不优的问题。并且源端可能会选择 Leader 节点，业务请求量较高时，可能导致业务请求和迁移任务较慢的问题。V4.2.3 版本根据地域将迁移复制的目标端和源端副本所在Server的关系划分为：同 IDC、同 Region 不同 IDC、跨 Region 三种区域，提供枚举配置项 choose_migration_source_policy，支持用户配置迁移复制选择源端副本的优先模式，以便优先考虑地理位置就近因素以及 Follower 副本来提升迁移效率、降低 Leader 压力。

• 数据盘满停写

  数据盘使用量过高时，当前不会停写用户请求，一直到内存因为无法转储写满，或者 Clog 盘写满后才会报错。这种情况下，需要通过紧急扩 Clog 盘或租户内存恢复。新版本在内核层面增加数据盘满停写功能，当用户数据盘水位线达到 data_disk_write_limit_percentage 配置后，用户写入请求会报错。通过删表、Transfer 或者扩磁盘方式降低数据盘使用比列后，用户写入操作可以自动恢复。

高可用增强

• 备份恢复支持 S3/OBS/GCS

  OceanBase 数据库的备份恢复功能支持两类存储介质：文件存储（NFS）和对象存储（OSS/COS）。新版本备份恢复扩展支持了 S3 及兼容 S3 协议的对象存储（如：OBS，GCS）作为备份介质，可以将 S3 及兼容 S3 协议的对象存储作为日志归档和数据备份的目的端，也可以使用 S3 及兼容 S3 协议的对象存储上的备份数据执行物理恢复。更多信息，参见 物理备份与恢复。

• SET/PIECE 级物理恢复

  实际业务中存在二次备份场景，会把数据备份集或归档日志手动搬迁到新的路径。OceanBase 数据库的物理恢复功能，限制了必须在租户的归档和备份路径中恢复，无法使用手动搬迁到新路径的备份数据，限制了恢复的灵活性。新版本增加了 SET/PIECE 级物理恢复功能，提供 add restore source 命令来加载新路径的数据备份集 SET 或日志归档 PIECE，允许按需恢复到指定时间。更多信息，参见 指定路径的恢复。

易用性提升

• OceanBase LogMiner

  V4.2.3_CE 版本新增 OceanBase LogMiner（简称 ObLogMiner）工具支持。ObLogMiner 是一款用来对 OceanBase 数据库进行日志分析的命令行工具，支持在线及离线的日志分析。ObLogMiner 通过 OBCDC 来拉取并解析 CLOG 日志，并将 OBCDC 输出的逻辑日志转化成易读的格式存储到指定位置。适用于以下场景：

  • 数据误操作：数据误操作可能由于多种原因出现，比如 WHERE 子句中的范围条件错误而误删除或更新了多余的行。通过使用 ObLogMiner 可以准确了解误操作的详细信息，以便于将数据库恢复到误操作之前的状态。
  • 数据分析：ObLogMiner 会将 CLOG 日志中的各种信息(事务、表结构等) 组织并友好地展示出来，用户可以借助 ObLogMiner 的输出结果进行多样的数据分析。也可以配合外表功能读取 ObLogMiner 的输出结果在数据库中进行查询分析。

  更多信息，参见 LogMiner 工具。

• Buffer 表自适应合并优化

  当用户在某张表上频繁地执行插入并且同时进行批量删除，或者有大量的并发更新操作时，可能会遇到一种现象：表中的数据行数并不大，但是查询和更新的性能出现明显下降。这种现象在 OceanBase 数据库中称为 Queuing 表(业务上有时又称 Buffer 表)效应。Buffer 表是 LSM-Tree 架构数据库都要面对的一类问题。LSM-Tree 架构下的删除操作在合并之前都只是逻辑上标记删除而非物理删除，当增量数据中存在大量标记删除的数据时，物理行数量将远多于逻辑行，从而造成严重的读放大现象，并影响优化器执行方案的生成。

  OceanBase 数据库在 V4.1.0 版本做到了自动识别哪些分区在一段时间内发生比较多更改，并对这些分区进行自适应 Compaction，但缺少人为控制手段。为了更灵活地解决 Buffer 表带来的性能下降问题，V4.2.3_CE 版本继续优化了 Buffer 表自适应合并特性，提供了 5 种档位的合并策略，允许用户根据业务场景为每张表设置不同的 table_mode，来应对 Buffer 表引起的读放大现象，从而提高系统长期运行下的 QPS 等性能指标。更多信息，参见 自适应合并。

• Format Outline

  OceanBase 比较早的版本就提供了通过创建 Outline 来绑定执行计划或指定 SQL 限流的功能（以下称为 Normal Outline），该功能对 SQL 文本的格式要求较为严格，除了可以参数化的部分之外，多一个空格、制表符或大小写不一致等情况都无法命中 Outline，SQL 格式不固定的场景易用性较差。V4.2.3_CE 版本新增 Format Outline 特性，提供了一种更为宽松的匹配规则。当用户创建 Format Outline 时，在 Outline 原有流程之前，系统会先做一次忽略大小写、空格等非语法定义符号的操作，归一化为标准格式，这使得归一化后得到同样 Format SQL Text 或 Format SQL ID 的用户请求都可以命中同一个 Format Outline。另外针对 INLIST 个数不固定的场景，如业务不固定下发 in(1,2)、 in(4,5,6)、in(7,8,9,10) 时 ，Normal Outline 精准匹配功能需要绑定 in(?,?)、in(?,?,?)、in(?,?,?,?) 三个 Outline 来控制执行计划；新版本的 Format Outline 功能只需绑定一次，系统会归一化为 in(?)，使得 INLIST 个数不同的多个 SQL 可以共享一个 Outline。当 Normal Outline 与 Format Outline 同时存在时，优先匹配 Normal Outline。更多信息，参见 CREATE FORMAT OUTLINE。

• 索引使用监控

  我们对数据库执行查询操作时，往往通过创建索引来优化查询性能。但随着数据表使用的时间增长，业务场景和操作人员不断增加，很可能会存在索引越建越多的问题。未使用的索引会浪费存储空间，也会加重 DML 操作的开销。对于这种情况，需要持续观察，删除无用的索引来给系统减负。但是仅靠人力很难识别哪些索引是无用索引，因此 OceanBase 数据库在 V4.2.3_CE 版本新增索引使用监控功能，用户可选择打开该功能并设置采样方式，在普通租户下会将符合规则的索引使用信息记录到内存，并以 15 分钟为周期刷新到内部表中，可通过 DBA_INDEX_USAGE 视图访问，以此来感知表上的索引是否有被引用，进而选择删除无用的索引表来释放空间。更多信息，参见 监控索引。

• 系统日志优化

  系统日志目录下，新增 ./alert/alert.log 日志文件，用于记录 DBA 关注的日志信息，初步解决 observer.log 日志量大、可读性差的问题。可通过 alert_log_level 集群级配置项设置日志级别，包括 INFO、WARN、ERROR 等。同时提供了系统外部表 sys_external_tbs.__all_external_alert_log_info 用于直接结构化查询 alert.log 日志信息。更多信息，参见 Alert 日志。

• 日志流副本管理

  V4.0.0 之前的版本，OceanBase 数据库提供了分区副本管理的一系列运维命令，比如为分区添加一个副本、为分区删除一个副本、对分区的一个副本进行类型转换等。V4.x 系列在设计上使用日志流代替了分区的概念，对标低版本的分区运维命令，V4.2.3_CE 版本重新设计实现了日志流副本级别任务的运维方式，提供了一系列语法，用于支持日志流副本的添加、删除、副本类型转换、迁移、修改日志流 Paxos 成员数量和取消容灾任务等能力，满足客户手动运维日志流副本的需求。更多信息，参见 副本管理。

• 物理恢复进度统计

  为了用户在使用物理恢复功能时可以了解恢复任务是否运行正常，获取恢复任务的进度情况，并预估恢复任务完成的剩余时间，在使用物理恢复功能时获得更好的体验，新版本增加物理恢复进度统计功能，可通过 CDB/DBA_OB_RESTORE_PROGRESS 视图随时查看恢复的实时进度。更多信息，参见 查看物理恢复进度。

• PX 诊断能力增强

  为方便分布式计划的问题排查，V4.2.3_CE 版本在 SQL Plan Monitor 中增加记录了算子运行时的内存使用量、磁盘使用量，整个执行过程的最大内存使用量、最大磁盘使用量等信息。并在 SQL Audit 中增加记录 QC 对应 trace_id 下的 MemTable、SSTable 行数信息，并支持汇总各 PX Worker 对应 trace_id 下的相关信息。同时也支持了 OBDiag 工具依据 trace_id 拉取最初报错机器日志的功能。

• PS 诊断能力增强

  V4.2.3_CE 之前的版本遇到 PS 句柄泄漏问题时，只能通过 GV$OB_PS_ITEM_INFO 视图查看全局信息，缺少 Session 级别的诊断方式。V4.2.3_CE 版本新增 [G]V$OB_SESSION_PS_INFO 系统视图，用于展示各个 Session 的 PS 引用信息，以便准确定位 PS 句柄泄漏等问题。

• ASH Report 节点级分析

  ASH Report 已支持生成集群级别的 ASH 分析报告，缺少节点级统计。如果想要查看某个节点上 ASH 数据，目前需要通过 SQL 脚本获取，这给单节点问题分析造成了一些不方便。V4.2.3_CE 版本增加 ASH Report 节点级分析能力，可通过 DBMS_WORKLOAD_REPOSITORY.ASH_REPORT 包函数中新增的两个参数（节点 IP 和 Port），指定单节点的 ASH Report 分析。更多信息，参见 ASH Report。

• 自增列 Cache Size 表级设定

  当前已支持通过指定租户级配置项 auto_increment_cache_size 来控制内存中自增列一次申请缓存的个数，对所有使用自增列的表生效。通常情况下，Cache Size 设置越大，性能会越好。但如果跳变次数很多，自增列字段取值上限又比较小，很可能导致自增列快速耗尽。V4.2.3_CE 版本新增自增列 Cache Size 表级设定功能，用户可以根据列类型/业务模型/业务流量等自定义配置不同表的缓存大小，从而做到跳变和性能的均衡。更多信息，参见 定义自增列。

• NETWORK_WAIT_TIME 统计项

  SQL AUDIT 和 SQLSTAT 中新增 NETWORK_WAIT_TIME 统计项，用于展示 NETWORK 类别的等待事件耗时，如同步 RPC、DAS 异步 RPC 锁等。在排查远程执行的慢 SQL 问题时，可以使用该统计项确认网络开销，辅助诊断。

• XA 事务监控统计项

  部分客户业务会采用 XA 协议来保证跨库事务提交的原子性。由于 OceanBase 数据库本身分布式架构特性，XA 语句的执行需要消耗一定的资源，该版本在 SYSSTAT 中新增 XA_TRANS_START_COUNT、XA_READ_ONLY_TRANS_TOTAL_COUNT、XA_ONE_PHASE_COMMIT_TOTAL_COUNT 等 30 余项统计项，便于在 XA 事务流量发生变化时，用户可以及时感知。更多信息，参见 监控项。

• Crash 日志中 SQL 信息打印场景完善

  Crash 日志中的 SQL 信息一方面可以用于问题排查，另一方面还可以被 OCP Agent 采集后发出告警。V4.2.3_CE 版本前，INNER SQL 主线程、用户 SQL 主线程 Crash 的情况下，Crash 日志里会打印 SQL 信息。但 REMOTE 线程、PX SQC 线程、PX WORKER 线程、DAS 远端执行线程 Crash 的时候日志里缺少 SQL 信息打印。新版本针对以上场景，支持了执行端获取 sql_id 或 sql_string 信息，如果执行端出现 Crash，将会在 Crash Error 日志中输出控制端的 SQL 信息，便于 Crash 原因定位。

• OBServer 支持 IPV6

  新版本支持 IPV6 格式的 Server IP，支持 SQL 客户端、RPC 客户端以 IPV6 地址连接，同时也支持了 IPV4 和 IPV6 节点的混合部署。支持 IPV4 集群升级，但不支持旧的 IPV4 类型的集群升级到 IPV6 类型。具体部署方式，参见 使用命令行部署单机集中式 OceanBase 数据库。

• GV$PLAN_CACHE_PLAN_EXPLAIN 视图支持仅指定 PLAN_ID 查询

  查询 [G]V$PLAN_CACHE_PLAN_EXPLAIN 视图时，必须同时指定 ip + port + tenant_id + plan_id 四个过滤条件才会返回数据，仅指定 plan_id 时返回结果为空，易用性较差。新版本支持了该视图的底层虚拟表扫描，允许仅指定 plan_id 进行数据查询，可准确返回查询结果。

• TRACE_ID 解析

  OceanBase 数据库通过 TRACE_ID 来标记 SQL 请求的全过程，用于关联监控指标或查询日志。TRACE_ID 包含了发起 SQL 请求的 OBServer 的 IP 和 Port 信息，但缺乏直接的解析方式。新版本增加 decode_trace_id 函数，用于解析 TRACE_ID 获取 IP、Port 相关信息。

兼容性变更

产品行为变更

新增如下变更：

视图变更

新增如下变更：

配置项变更

系统变量变更

函数/系统包变更

语法变更

周边配套

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

升级说明

• 支持 OceanBase 数据库 V4.2.1_CE_BP2 及之前的 V4.x_CE 版本通过有效升级路径在线升级到 OceanBase 数据库 V4.2.3_CE_BETA 版本。V4.2.1_CE_BP3 及之后的 BP 版本目前不再支持升级到 V4.2.3_CE_BETA 版本。
• 支持 OceanBase 数据库 V4.2.2_CE 版本经停 V4.2.2_CE_BP1 版本，在线升级到 V4.2.3_CE_BETA 版本。
• V4.2.1_CE 及 V4.2.2_CE 系列的版本升级到 V4.2.3_CE_BETA 版本时，需要将系统变量 _nlj_batching_enabled 设为 False。升级完成后可以打开。
• 集群 Tablet 比较多的情况下，升级过程中 OBServer 重启会比较耗时。已知 300w+ 的 Tablet，重启时长大约在 20min，存在大量 Tablet 的场景需要特别注意预留足够的升级时间。
• ODP 和 OBServer 升级顺序：建议先升级 OBServer 版本再升级 ODP 版本。
• 升级期间，系统会自动禁用合并和 DDL 操作，升级完成后恢复正常使用。

开源鸣谢

在此版本发布中，特别感谢社区伙伴的贡献：

感谢联通软研院团队邱永刚 @qiuyg3 在 ObLogMiner 功能上的贡献。