使用数据编码和压缩 - OceanBase 数据库 V5.0.1

使用数据编码和压缩

更新时间：2026-07-29 10:39:51

编辑

OceanBase 数据库支持 MySQL 和 Oracle 两种模式的租户，为了兼容不同类型用户的使用习惯，OceanBase 数据库在不同模式中提供了不同类型的配置方式来使用数据编码和数据压缩。

OceanBase 数据库支持通过 DDL 来对表级别的压缩或编码方式进行配置。

MySQL 模式下设置数据的压缩与编码方式

在 MySQL 模式下创建表或修改表时，您可以通过 row_format 和 compression 来设置编码格式及压缩方式。

语句如下：

创建表时，指定表的编码格式和压缩方式
```
CREATE TABLE table_name table_definition_list 
ROW_FORMAT [=] row_format COMPRESSION [=] 'compression';
```
更多 CREATE TABLE 语句的说明请参见 CREATE TABLE。

修改表时，更改表的编码格式和压缩方式

ALTER TABLE table_name [alter_table_action_list] [SET] ROW_FORMAT [=]row_format COMPRESSION [=]  'compression';

更多 ALTER TABLE 语句的说明请参见 ALTER TABLE。

row_format 的取值如下：

REDUNDANT 和 COMPACT：表示数据不会被编码，数据以 flat 格式被保存。
DYNAMIC：表示数据会被编码，数据以 encoding 格式被保存，默认取值为 DYNAMIC。
COMPRESSED：表示数据会被编码，数据以 encoding 格式被保存。
CONDENSED：表示数据会被编码，数据以 selective encoding 格式被保存。

selective encoding 格式是 encoding 格式的子集，仅使用查询更友好的编码方式。

compression 的取值如下：

说明

由于 zlib 不同小版本的压缩算法可能存在对同一数据进行压缩后，出现压缩结果不一致的情况，为了避免 OceanBase 数据库在升级过程中出现无法恢复副本数据的问题，对于 V4.3.x 版本，从 V4.3.0 版本开始，OceanBase 数据库不再支持 zlib_1.0 压缩算法。

none：表示数据不压缩。
lz4_1.0：表示指定压缩算法为 lz4_1.0。
snappy_1.0：表示指定压缩算法为 snappy_1.0。
zstd_1.0：表示指定压缩算法为 zstd_1.0。
zstd_1.3.8：表示指定压缩算法为 zstd_1.3.8。默认取值为 zstd_1.3.8。
lz4_1.9.1：表示指定压缩算法为 lz4_1.9.1。

示例如下：

创建表时指定编码格式和压缩方式

执行以下语句，在创建表时指定表的编码格式为 encoding 格式和压缩方式为 zstd_1.0。

obclient> CREATE TABLE test (
 id INT NOT NULL,
 fname VARCHAR(30),
 lname VARCHAR(30),
 hired DATE NOT NULL DEFAULT '1970-01-01',
 separated DATE NOT NULL DEFAULT '9999-12-31',
 job_code INT NOT NULL,
 store_id INT NOT NULL
) ROW_FORMAT=CONDENSED COMPRESSION='zstd_1.0';

修改表时，更改表的编码格式和压缩方式

执行以下语句，将表的编码格式修改为 selective encoding 格式，压缩方式修改为 lz4_1.0。
```
obclient> ALTER TABLE test SET ROW_FORMAT = CONDENSED COMPRESSION = 'lz4_1.0';
```

Oracle 模式下设置数据的压缩与编码方式

在 Oracle 模式下创建表或修改表时，也可以指定数据的编码格式和压缩方式。

语句如下：

创建表时，指定编码格式和压缩方式
```
CREATE TABLE table_name table_definition_list compression;
```
更多 CREATE TABLE 语句的说明请参见 CREATE TABLE。
修改表时，更改表的编码格式和压缩方式
```
ALTER TABLE table_name [alter_table_action_list] compression;
```
更多 ALTER TABLE 语句的说明请参见 ALTER TABLE。

其中，compression 的取值如下：

NOCOMPRESS：表示数据不会被编码或压缩，数据以 flat 格式被保存。
COMPRESS BASIC：表示数据不会被编码，数据以 flat 格式被保存，并使用 lz4_1.0 压缩。
COMPRESS FOR OLTP：表示数据不会被编码，数据以 flat 格式被保存，并使用 zstd_1.3.8 压缩。
COMPRESS FOR QUERY：表示数据会被编码，数据以 encoding 格式被保存，并使用 lz4_1.0 压缩。
COMPRESS FOR ARCHIVE：表示数据会被编码，数据以 encoding 格式被保存，并使用 zstd_1.3.8 压缩。默认取值为 COMPRESS FOR ARCHIVE。
COMPRESS FOR ARCHIVE HIGH：表示数据会被编码，数据以 encoding 格式被保存，并使用 zstd_1.3.8 压缩。
COMPRESS FOR QUERY LOW：表示数据会被编码，数据以 selective encoding 格式被保存，并使用 lz4_1.0 压缩。

selective encoding 格式是 encoding 格式的子集，仅使用查询更友好的编码方式。

示例如下：

创建表时指定编码格式和压缩方式

执行以下语句，在创建表时指定表的编码格式为 encoding 格式，压缩方式为 lz4_1.0。

obclient> CREATE TABLE test (
id number NOT NULL,
fname VARCHAR2(30),
lname VARCHAR2(30),
hired DATE NOT NULL DEFAULT sysdate,
separated DATE,
job_code INT NOT NULL,
store_id INT NOT NULL
) COMPRESS FOR QUERY;

修改表时，更改表的编码格式和压缩方式

执行以下语句，修改表的编码格式为 encoding 格式，同时压缩方式为 zstd_1.3.8。
```
obclient> ALTER TABLE test COMPRESS FOR ARCHIVE;
```

设置转储数据的存储格式

在之前的版本中，OceanBase 数据库转储数据的存储格式仅支持 flat 格式。在面对增量数据较多的场景时，flat 格式成为了性能瓶颈。在 V4.6.x 版本中，为了提高 OLAP 场景的查询性能，降低增量数据的存储空间，OceanBase 数据库从 V4.6.0 版本开始支持转储数据使用 encoding 格式。用户可以通过表属性 delta_format 来指定转储数据的存储格式。

注意

更改转储数据的存储格式后，系统将会在之后的转储中使用 encoding 格式存储增量数据，并且不会重写已有的增量数据。

创建表时，指定转储数据的存储格式
```
CREATE TABLE table_name delta_format = 'flat | encoding' ;
```
说明

或者，用户也可以在建表时不指定转储数据的存储格式，直接通过租户级配置项 default_delta_format 来指定所有新建表的转储格式。
修改表时，更改转储数据的存储格式
```
ALTER TABLE table_name SET delta_format = 'flat | encoding';
```
语句中，delta_format 支持以下两种取值：
- flat：表示转储数据使用 flat 格式。flat 格式是默认的转储格式，面向 OLTP 场景，写入速度快，压缩率低，但对 OLAP 场景的查询不友好。
- encoding：表示转储数据使用 encoding 格式。面向 OLAP 场景，写入相对较慢，压缩率高，对 OLAP 场景的查询友好，在 delete_insert 表上会有更明显的效果。

示例如下：

MySQL 模式

Oracle 模式

创建表 t1 时，指定表 t1 的转储数据的存储格式为 encoding 格式。

obclient(root@mysql001)[test]> CREATE TABLE t1(col1 int, col2 float) delta_format = 'encoding';

修改表 t2 时，更改表 t2 的转储数据的存储格式为 encoding 格式。
```
obclient(root@mysql001)[test]> ALTER TABLE t2 SET delta_format = 'encoding';
```
语句执行成功后，系统会有一定的延时（大约 2 分钟），待修改生效后，系统将会在之后的转储中使用 encoding 格式存储增量数据（不会重写已有的增量数据）。

创建表 T1 时，指定表 T1 的转储数据的存储格式为 encoding 格式。

obclient(SYS@oracle001)[SYS]> CREATE TABLE T1(col1 int, col2 float) delta_format = 'encoding';

修改表 T2 时，更改表 T2 的转储数据的存储格式为 encoding 格式。
```
obclient(SYS@oracle001)[SYS]> ALTER TABLE T2 SET delta_format = 'encoding';
```
语句执行成功后，系统会有一定的延时（大约 2 分钟），待修改生效后，系统将会在之后的转储中使用 encoding 格式存储增量数据（不会重写已有的增量数据）。

对已经生成 SSTable 的表更改压缩方式

对已经生成了 SSTable 的表进行压缩选项的变更时，为了避免给一次合并带来太大的 IO 写入压力，需要通过渐进合并的方式逐渐重写全部的微块数据，来完成压缩方式的变更。渐进合并的轮次可以通过在 ALTER TABLE 语句中设置 progressive_merge_num 的值来完成。

具体方法如下：

租户管理员登录到数据库。
执行以下语句，设置渐进合并轮次。

progressive_merge_num 用于设置表的渐进合并的轮次，默认为 0，表示进行增量合并。如果值设置为 1，则表示进行全量合并。

设置渐进合并轮次为 2 次的示例如下：
```
obclient> ALTER TABLE t1 SET progressive_merge_num=2;
```
设置成功后，后续系统会在每日合并中逐渐完成数据的重写。

说明

如果希望尽快完成数据的重写，可以将 progressive_merge_num 的值设置为 1 后，手动发起一次合并，手动发起合并的操作请参见手动触发合并。

更改压缩选项。

MySQL 模式下更改压缩选项的操作请参见本节 MySQL 模式下设置数据的压缩与编码方式。

Oracle 模式下更改压缩选项的操作请参见本节 Oracle 模式下设置数据的压缩与编码方式。