---
title: "体验 HTAP 混合负载场景 - OceanBase 数据库 V5.0.1 | OceanBase 文档中心"
description: 体验 HTAP 混合负载场景 OceanBase 数据库采用一体化架构，同一套引擎、同一份数据即可同时支撑在线交易（TP）和实时分析（AP）负载。通过行存列存一体化存储技术，OceanBase 在同一张表上既能高效处理高并发点查与短事务更新，又能执行大范围扫描与聚合分析，无需维护分离的 OLTP 与 OLAP 系统。…
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 5.0.1

# 体验 HTAP 混合负载场景

更新时间：2026-10-27 15:56:46

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V5.0.1/zh-CN/200.quickstart/300.experience-htap-hybrid-workload.md)  

OceanBase 数据库采用一体化架构，同一套引擎、同一份数据即可同时支撑在线交易（TP）和实时分析（AP）负载。通过行存列存一体化存储技术，OceanBase 在同一张表上既能高效处理高并发点查与短事务更新，又能执行大范围扫描与聚合分析，无需维护分离的 OLTP 与 OLAP 系统。

本文将引导您完成以下体验：

- **创建 HTAP 测试表**：创建行列混存表，同一份数据同时保持行存与列存两种基线形态。
 - **体验 TP 业务**：在混存表上执行写入、更新和主键点查，体验行存路径的高效事务处理。
 - **体验 AP 业务**：在同一张表上执行复杂分析查询，体验列存路径的向量化扫描与聚合能力。
 - **体验资源隔离**：配置租户内资源组，观察 AP 大查询对 TP 负载的影响及启用资源隔离后的改善。

#### 说明

本文基于 OceanBase 数据库 V5.0.1（社区版）撰写，文中相关命令和功能说明均以 V5.0.1 版本为准。本文以 [部署 OceanBase](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615008) 中使用 All in One 安装包部署的单节点环境为例，需已按 [体验高并发 OLTP 场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140970) 创建测试租户 `oltp_tenant`。如使用 RPM 包（systemd）部署，请同样使用已创建的业务租户进行操作。

## 前提条件

在开始本文操作前，确保满足以下条件：

| 项目 | 描述 |
| --- | --- |
| OceanBase 数据库 | 已完成部署并成功启动，参见 [部署 OceanBase](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615008)。 |
| 测试租户 | 已创建 MySQL 模式业务租户（如 `oltp_tenant`），参见 [体验高并发 OLTP 场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140970)。 |
| 数据库版本 | 建议使用 OceanBase V4.3.0 及以上版本（本文基于 V5.0.1），列存与行列混存功能自 V4.3.0 版本开始支持。 |
| obclient | 已安装 obclient 并可正常连接业务租户。 |
| cgroup | 体验资源隔离中的 CPU 隔离功能需要配置 cgroup，详细信息请参见 [配置 cgroup](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006619066)。 |

## 创建 HTAP 测试表

### 关于行存、列存与行列混存

OceanBase 默认建表为行存表。通过 `WITH COLUMN GROUP` 选项，可以指定不同的存储格式：

| 存储格式 | WITH COLUMN GROUP 写法 | 适用场景 |
| --- | --- | --- |
| 行存 | `WITH COLUMN GROUP(all columns)` | 纯 OLTP，以点查和短事务更新为主 |
| 列存 | `WITH COLUMN GROUP(each column)` | 纯 OLAP，以大范围扫描和聚合分析为主 |
| 行列混存 | `WITH COLUMN GROUP(all columns, each column)` | HTAP，同一张表同时服务 TP 和 AP 负载 |

行列混存表同时保留行存基线与列存基线，优化器会根据查询特征自动选择访问路径：点查倾向走行存路径，宽范围扫描倾向走列存路径。详细信息请参见 [使用列存与行列混存](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006627447)。

### 操作步骤

1. 登录业务租户（`oltp_tenant` 租户的 root 用户密码默认为空，提示输入密码时直接回车即可登录）：

   ```shell
   obclient -h127.0.0.1 -uroot@oltp_tenant -P2881 -p -A test

   ```
 2. 创建行列混存表。以支付流水业务为例：

   ```sql
   obclient [test]> CREATE TABLE payment_ledger_htap (
       txn_id       BIGINT       NOT NULL COMMENT '流水号',
       order_id     BIGINT       NOT NULL COMMENT '订单号',
       user_id      BIGINT       NOT NULL COMMENT '用户ID',
       pay_time     DATETIME     NOT NULL COMMENT '支付时间',
       pay_channel  VARCHAR(32)  NOT NULL COMMENT '支付渠道',
       txn_status   TINYINT      NOT NULL COMMENT '0待支付 1成功 2失败',
       amount       DECIMAL(18,2) NOT NULL COMMENT '金额',
       merchant_id  BIGINT       NOT NULL COMMENT '商户ID',
       PRIMARY KEY (order_id, pay_time, txn_id)
   )
   PARTITION BY HASH(order_id) PARTITIONS 4
   WITH COLUMN GROUP(all columns, each column);

   ```

   #### 说明

   `WITH COLUMN GROUP(all columns, each column)` 同时声明行存列组与列存列组，基线冗余两份。优化器可按代价在点查走行存路径、在宽范围扫描走列存路径。
 3. 写入测试数据：

   ```sql
   obclient [test]> INSERT INTO payment_ledger_htap (txn_id, order_id, user_id, pay_time, pay_channel, txn_status, amount, merchant_id)
   VALUES
       (1, 1001, 100, '2025-01-15 10:30:00', 'ALIPAY', 1, 128.50, 2001),
       (2, 1002, 101, '2025-01-15 11:00:00', 'WECHAT', 1, 256.00, 2002),
       (3, 1003, 100, '2025-01-15 14:20:00', 'ALIPAY', 2, 99.90,  2001),
       (4, 1004, 102, '2025-01-15 16:45:00', 'UNIONPAY', 1, 1024.00, 2003),
       (5, 1005, 101, '2025-01-16 09:00:00', 'WECHAT', 1, 56.80, 2002);

   ```
 4. （可选）批量写入更多数据。上述示例数据仅 5 行，用于快速走通操作流程；数据量较小时，优化器不会为分析查询选择列存路径，后续步骤中的部分效果也不易观察。如希望完整体验 AP 查询的列存路径，可执行以下语句批量写入约 100 万行测试数据（实际耗时与机器性能相关）。

   单条 SQL 语句默认的执行超时时间为 10 秒，递归 CTE 默认的递归深度限制为 1000，批量写入数据耗时较长且数据量大，均需先调大。此处将执行超时时间调整为 60 秒（如仍报 `ERROR 4012` 超时，可继续调大）并将递归深度调整为 1100000：

   ```sql
   obclient [test]> SET SESSION ob_query_timeout = 60000000, cte_max_recursion_depth = 1100000;

   ```

   执行以下语句批量写入数据：

   ```sql
   obclient [test]> INSERT INTO payment_ledger_htap
                   WITH RECURSIVE seq(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM seq WHERE n < 1000000)
                   SELECT n+1000000, 3000000+n, 100+(n%50),
                          DATE_ADD('2025-01-15 00:00:00', INTERVAL (n%20000) MINUTE),
                          ELT(1+(n%3),'ALIPAY','WECHAT','UNIONPAY'), 1+(n%2),
                          ROUND(RAND()*1000,2), 2000+(n%10)
                   FROM seq WHERE n <= 1000000;

   ```
 5. 执行合并操作并收集统计信息，以改善列存查询性能：

   ```sql
   -- 在 sys 租户中触发合并
   obclient [oceanbase]> ALTER SYSTEM MAJOR FREEZE;

   ```

   ```sql
   -- 在业务租户中收集统计信息
   obclient [test]> CALL DBMS_STATS.GATHER_SCHEMA_STATS('test');

   ```

   #### 说明

   合并（Major Compaction）是 OceanBase 将增量数据整理为基线数据的后台操作，新写入的数据需经过合并进入基线层后，才能被列存路径高效读取。合并状态可通过查询 `oceanbase.CDB_OB_ZONE_MAJOR_COMPACTION` 视图确认，当 `STATUS` 显示为 `IDLE` 时表示合并完成，实际耗时与数据量相关。`DBMS_STATS` 系统包收集统计信息的详细说明请参见 [手动统计信息收集](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006621034)。

## 体验 TP 业务

行列混存表中，点查和高频短事务更新通过行存路径处理，具备与传统行存表相当的事务处理性能。

### 操作步骤

obclient 默认会在查询结果后显示执行耗时，例如 `1 row in set (0.00 sec)`，无需额外开启计时。下述各步骤的查询响应时间（RT）均可通过该显示直接观察。

1. **写入数据**（模拟新增支付流水）：

   ```sql
   obclient [test]> INSERT INTO payment_ledger_htap (txn_id, order_id, user_id, pay_time, pay_channel, txn_status, amount, merchant_id)
   VALUES (6, 1006, 103, '2025-01-16 10:00:00', 'ALIPAY', 1, 388.00, 2001);

   ```
 2. **更新数据**（模拟支付状态变更）：

   ```sql
   obclient [test]> UPDATE payment_ledger_htap SET txn_status = 1 WHERE order_id = 1003;

   ```
 3. **主键点查**（模拟按订单号查询流水）：

   ```sql
   obclient [test]> SELECT txn_id, pay_time, amount, pay_channel
                   FROM payment_ledger_htap
                   WHERE order_id = 1001 AND txn_status = 1
                   ORDER BY pay_time DESC
                   LIMIT 1;

   ```

   对于主键点查，响应时间通常在毫秒级甚至亚毫秒级，体现了行存路径的点查效率。

   #### 说明

   上述查询倾向走行存路径，通过主键快速定位数据。可使用 `EXPLAIN` 查看执行计划确认访问路径。

## 体验 AP 业务

同一张行列混存表上，复杂分析查询会倾向走列存路径，仅扫描涉及列，利用向量化执行引擎加速聚合与扫描。

### 操作步骤

1. **按渠道汇总支付金额**（聚合分析查询）：

   ```sql
   obclient [test]> SELECT pay_channel, SUM(amount) AS total_amt, COUNT(*) AS cnt
                   FROM payment_ledger_htap
                   WHERE pay_time >= '2025-01-15 00:00:00'
                     AND pay_time <  '2025-01-17 00:00:00'
                     AND txn_status = 1
                   GROUP BY pay_channel;

   ```
 2. **按商户统计支付总额**：

   ```sql
   obclient [test]> SELECT merchant_id, DATE(pay_time) AS dt, SUM(amount) AS daily_amt
                   FROM payment_ledger_htap
                   WHERE pay_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
                     AND txn_status = 1
                   GROUP BY merchant_id, DATE(pay_time);

   ```
 3. 使用 `EXPLAIN` 查看执行计划，确认是否走列存路径：

   ```sql
   obclient [test]> EXPLAIN SELECT pay_channel, SUM(amount) FROM payment_ledger_htap
                   WHERE pay_time >= '2025-01-01' GROUP BY pay_channel;

   ```

   #### 说明

   如果执行计划中出现 `COLUMN TABLE FULL SCAN` 等列存相关算子，表示查询走了列存路径。数据量较小时（如仅写入示例的 5 行数据），优化器可能选择行存路径（显示 `TABLE FULL SCAN`），属于正常现象，批量写入数据并完成合并后即可观察到列存路径。实际执行计划以当前版本输出为准。

   TP 点查走行存路径，通常在毫秒级完成；AP 聚合查询由于需要扫描全表数据，响应时间会随数据量增加而上升。得益于列存仅扫描涉及列并配合向量化引擎加速，相同查询在行列混存表上仍能保持较高的执行效率。

## 体验资源隔离

在 HTAP 场景中，AP 大查询可能消耗大量 CPU 和 IO 资源，影响同时运行的 TP 业务。OceanBase 数据库支持通过**资源组（Resource Group）** 实现租户内的资源隔离，将 TP 和 AP 负载分配到不同的资源组，各自限制 CPU 和 IOPS 使用上限，确保 AP 查询不会干扰 TP 事务。

### 资源隔离原理

| 状态 | TP 延迟 | 说明 |
| --- | --- | --- |
| 未启用资源隔离 | 可能飙升 | AP 大查询与 TP 事务共享资源，AP 占用过多 CPU/IO 时 TP 响应变慢 |
| 启用资源隔离后 | 保持稳定 | TP 和 AP 分别绑定不同资源组，各自受 CPU/IOPS 上限约束，互不干扰 |

#### 说明

资源隔离通过资源组、资源管理计划和资源管理计划内容三个层级实现。详细信息请参见 [配置租户内资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006619072)。

### 操作步骤

#### 1. 创建测试用户

在业务租户中创建 TP 和 AP 专用用户：

```sql
obclient [test]> CREATE USER tp_user IDENTIFIED BY '******';
obclient [test]> CREATE USER ap_user IDENTIFIED BY '******';
obclient [test]> GRANT ALL PRIVILEGES ON test.* TO tp_user;
obclient [test]> GRANT SELECT ON test.* TO ap_user;

```

#### 2. 创建资源组

调用 `DBMS_RESOURCE_MANAGER` 系统包，创建 TP 和 AP 两个资源组：

```sql
-- 创建 TP 资源组
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    CONSUMER_GROUP => 'tp_group',
    COMMENT => 'TP 业务资源组'
);

-- 创建 AP 资源组
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    CONSUMER_GROUP => 'ap_group',
    COMMENT => 'AP 业务资源组'
);

```

#### 3. 创建资源管理计划

```sql
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN => 'htap_plan',
    COMMENT => 'HTAP 资源隔离计划'
);

```

#### 4. 创建资源管理计划内容

为 TP 资源组分配 80% CPU 上限，为 AP 资源组分配 30% CPU 上限：

```sql
-- TP 资源组：CPU 上限 80%
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN => 'htap_plan',
    GROUP_OR_SUBPLAN => 'tp_group',
    COMMENT => 'TP 资源限制',
    UTILIZATION_LIMIT => 80,
    MIN_IOPS => 50,
    MAX_IOPS => 90
);

-- AP 资源组：CPU 上限 30%
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN => 'htap_plan',
    GROUP_OR_SUBPLAN => 'ap_group',
    COMMENT => 'AP 资源限制',
    UTILIZATION_LIMIT => 30,
    MIN_IOPS => 20,
    MAX_IOPS => 60
);

```

| 参数 | 说明 |
| --- | --- |
| `UTILIZATION_LIMIT` | 资源组使用的 CPU 资源上限，取值范围 (0, 100]。`80` 表示最大可使用租户 80% 的 CPU 资源。 |
| `MIN_IOPS` | 出现 IO 争用时的预留 IOPS 资源，总和不超过 100。 |
| `MAX_IOPS` | 资源组最大可使用的 IOPS 资源，总和可以超过 100。 |

#### 5. 绑定用户到资源组

将 `tp_user` 绑定到 `tp_group`，`ap_user` 绑定到 `ap_group`：

```sql
obclient [test]> CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    ATTRIBUTE => 'user',
    VALUE => 'tp_user',
    CONSUMER_GROUP => 'tp_group'
);

obclient [test]> CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    ATTRIBUTE => 'user',
    VALUE => 'ap_user',
    CONSUMER_GROUP => 'ap_group'
);

```

#### 说明

除了通过 User 级别绑定资源组外，OceanBase 还支持通过 Hint 方式在 SQL 级别指定资源组，例如：`SELECT /*+resource_group('ap_group')*/ ...`。详细信息请参见 [配置租户内资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006619072)。

#### 6. 启用资源管理计划

```sql
obclient [test]> SET GLOBAL resource_manager_plan = 'htap_plan';

```

执行以下语句确认启用成功（`SET GLOBAL` 语句仅修改全局值，当前会话需通过 `SHOW GLOBAL VARIABLES` 查看）：

```sql
obclient [test]> SHOW GLOBAL VARIABLES LIKE 'resource_manager_plan';

```

返回结果中 `Value` 为 `htap_plan` 即表示启用成功。启用后，`tp_user` 执行的 SQL 将使用 `tp_group` 的资源配额，`ap_user` 执行的 SQL 将使用 `ap_group` 的资源配额。

#### 7. 验证资源隔离效果

通过对比"未启用资源隔离"和"启用资源隔离"两种状态下 TP 点查的响应时间，直观感受资源隔离的作用。建议在两个终端窗口中分别操作。

**准备两个连接：**

- 终端 A：使用 `tp_user` 连接：

  ```shell
  obclient -h127.0.0.1 -utp_user@oltp_tenant -P2881 -p -A test

  ```
 - 终端 B：使用 `ap_user` 连接：

  ```shell
  obclient -h127.0.0.1 -uap_user@oltp_tenant -P2881 -p -A test

  ```

终端中执行的每条查询语句都会在结果后显示执行耗时（如 `N rows in set (X.XX sec)`），后续通过对比终端 A 中 TP 点查的耗时变化观察资源隔离效果。

**第一步：未启用资源隔离时**

1. 先临时禁用资源隔离计划，确保 TP 和 AP 共享资源：

   ```sql
   obclient [test]> SET GLOBAL resource_manager_plan = '';

   ```
 2. 在终端 A 中执行一次 TP 点查，记录响应时间作为基准值：

   ```sql
   obclient [test]> SELECT txn_id, pay_time, amount FROM payment_ledger_htap WHERE order_id = 1001;

   ```

   此时没有 AP 负载干扰，点查响应时间通常在毫秒级。
 3. 在终端 B 中发起 AP 聚合查询（数据量越大，查询耗时越长，效果越明显）：

   ```sql
   obclient [test]> SELECT pay_channel, SUM(amount), COUNT(*) FROM payment_ledger_htap GROUP BY pay_channel;

   ```
 4. **在 AP 查询执行期间**，回到终端 A 重复执行 TP 点查，观察响应时间。由于 AP 查询与 TP 事务共享 CPU 和 IO 资源，AP 查询占用大量资源时，TP 点查的响应时间可能出现明显升高。

**第二步：启用资源隔离后**

1. 重新启用资源隔离计划：

   ```

   执行 `SHOW GLOBAL VARIABLES LIKE 'resource_manager_plan';` 确认返回值为 `htap_plan`。
 2. 在终端 B 中再次发起 AP 聚合查询：

   ```
 3. **在 AP 查询执行期间**，回到终端 A 重复执行 TP 点查，观察响应时间。启用资源隔离后，AP 查询被限制在 `ap_group` 的 CPU 上限（30%）内，TP 事务享有 `tp_group` 的资源保障，TP 点查的响应时间应保持稳定，不会因 AP 查询而出现明显波动。

**结果对比：**

| 状态 | TP 点查响应时间 | 原因 |
| --- | --- | --- |
| 未启用资源隔离 | 可能升高 | AP 大查询与 TP 事务共享资源，AP 占用过多 CPU/IO 导致 TP 延迟飙升 |
| 启用资源隔离后 | 保持稳定 | TP 和 AP 分别绑定不同资源组，各自受 CPU/IOPS 上限约束，互不干扰 |

无论延迟差异是否明显，均可使用 `oltp_tenant` 的 root 用户登录 oceanbase 库后（普通用户无权查询相关视图）执行以下语句确认资源隔离已生效：

```sql
obclient [oceanbase]> SELECT * FROM oceanbase.V$RSRC_PLAN;

```

返回结果中 `NAME` 为 `htap_plan` 且 `CPU_MANAGED` 为 `ON`，表示资源管理计划已启用。也可执行以下语句查看各资源组的资源限制详情：

```sql
obclient [oceanbase]> SELECT PLAN, GROUP_OR_SUBPLAN, UTILIZATION_LIMIT, MIN_IOPS, MAX_IOPS FROM oceanbase.DBA_OB_RSRC_DIRECTIVES;

```

返回结果中可以看到 `tp_group` 与 `ap_group` 的 CPU 与 IOPS 上限配置。

#### 注意

- 资源隔离的延迟改善效果取决于 AP 负载的强度与持续时间：只有当 AP 查询消耗大量资源且持续较长时间（如多个会话并发执行大范围分析查询）时，TP 与 AP 的资源争用才容易观察。在本文的轻量示例环境中，即使批量写入了数据，TP 点查的延迟差异也可能不明显，这不代表资源隔离未生效（可通过上述视图确认）。如需更明显的对比效果，可参考 [体验高并发 OLTP 场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140970) 使用 Sysbench 压测作为 TP 负载。
 - 资源隔离匹配规则添加后预计在 10 秒内开始生效，具体以实际环境为准。
 - 如需禁用资源隔离计划，可执行 `SET GLOBAL resource_manager_plan = '';`

## 下一步

完成本文的 HTAP 体验后，您可以继续以下探索之旅：

1. **体验 AI 场景**：创建向量表和全文索引，体验 OceanBase 数据库的混合检索能力。详见 [体验 AI 场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140972)。
 2. **体验多租户特性**：创建多个业务租户，体验集群级资源隔离和弹性扩缩容。详见 [体验多租户与资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140973)。
 3. **深入了解 AP 能力**：探索列存索引、物化视图、并行查询等 OceanBase AP 核心特性。详见 [OceanBase AP 概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615040)。

## 相关文档

- 列存与行列混存的完整说明请参见 [使用列存与行列混存](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006627447)。
 - OceanBase AP 核心特性和应用场景请参见 [OceanBase AP 概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615040)。
 - 资源隔离的完整配置方法和注意事项请参见 [配置租户内资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006619072)。
 - 资源隔离的基础概念和适用场景请参见 [资源隔离概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616133)。
 - 表创建和存储格式相关的配置项请参见 [default_table_store_format](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006618718)。

 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线