---
title: "体验多租户与资源隔离 - OceanBase 数据库 V5.0.1 | OceanBase 文档中心"
description: 体验多租户与资源隔离 多租户是 OceanBase 数据库区别于传统单实例数据库的核心能力。OceanBase 采用单集群多租户架构，在集群层面实现了实例资源的池化，每一个租户即一个实例（类比 MySQL Instance），租户与租户之间数据、权限、资源完全隔离，每个租户拥有独立的用户体系及专属的 CPU、内存等资…
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

# 体验多租户与资源隔离

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

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V5.0.1/zh-CN/200.quickstart/500.experience-multi-tenant-and-resource-isolation.md)  

多租户是 OceanBase 数据库区别于传统单实例数据库的核心能力。OceanBase 采用单集群多租户架构，在集群层面实现了实例资源的池化，每一个租户即一个实例（类比 MySQL Instance），租户与租户之间数据、权限、资源完全隔离，每个租户拥有独立的用户体系及专属的 CPU、内存等资源。通过多租户机制，一个集群可以同时承载多个业务，在保证可用性和性能的前提下高效利用资源，并做到按需弹性扩缩容。

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

- **理解多租户架构**：掌握资源配置（Unit Config）、资源池（Resource Pool）、资源单元（Unit）与租户（Tenant）的基本关系。
 - **创建不同业务租户**：为不同业务创建相互隔离的租户，并配置不同的 CPU、内存、存储等资源规格。
 - **验证租户间隔离性**：在不同租户中执行查询，观察数据与权限的边界。
 - **在线调整资源规格**：体验租户资源的在线扩缩容，变更过程对业务无感知。
 - **压测观察租户性能**：在业务租户中执行标准压测，验证租户可正常承载业务流量，并理解资源配额的隔离逻辑。

#### 说明

本文基于 OceanBase 数据库 V5.0.1（社区版）撰写，文中相关命令和功能说明均以 V5.0.1 版本为准。本文以 [部署 OceanBase](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615008) 中使用 All in One 安装包部署的单节点环境为例。本文聚焦**租户间**的资源隔离，即通过资源规格划分各租户可用的资源上限；如需体验**同一租户内**不同负载之间的资源隔离（资源组），请参见 [体验 HTAP 混合负载场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140971)。

## 前提条件

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

| 项目 | 描述 |
| --- | --- |
| OceanBase 数据库 | 已完成部署并成功启动，参见 [部署 OceanBase](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615008)。 |
| 机器资源 | 建议不低于 4 核 CPU、16 GB 内存。机器资源越多，可为租户分配的规格越大。 |
| sys 租户访问 | 可使用 root 用户登录集群的 sys 租户执行管理操作。sys 租户 root 用户的密码为部署时随机生成的密码，可在部署输出或 `obd cluster display demo` 命令的输出中查看。 |
| obclient | 已安装 obclient 并可正常连接 OceanBase 数据库。使用 All in One 安装包部署时已自动安装。 |
| ob-sysbench（可选） | 如需体验压测观察租户性能，需已按 [体验高并发 OLTP 场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140970) 安装 ob-sysbench。 |

## 多租户架构简介

OceanBase 数据库通过租户实现资源隔离，让每个数据库服务的实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性。租户是一个逻辑概念，既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器，在一定程度上相当于传统数据库的"实例"概念。

OceanBase 使用以下三个概念对各租户的可用资源进行管理：

| 概念 | 说明 |
| --- | --- |
| 资源配置（Unit Config） | 描述资源单元可用的 CPU、内存、存储空间和 IOPS 等规格的配置信息。修改资源配置可动态调整资源单元的规格。 |
| 资源单元（Unit） | 租户使用 CPU、内存的最小逻辑单元，也是集群扩展和负载均衡的基本单位。一个 Unit 必须放置在资源足够容纳它的物理机上，且单台物理机上最多能放置同一个资源池下的一个 Unit。 |
| 资源池（Resource Pool） | 由若干个资源单元组成，通过给资源池指定资源配置，可确定资源池下各资源单元的物理资源。一个资源池仅能属于一个租户，一个租户可拥有一个或多个资源池。 |

由于分布式的架构，一个 OceanBase 租户可以在资源规格、资源池、副本类型、副本分布几个维度灵活定义，因此创建租户时需要按照 **资源配置 → 资源池 → 租户** 的顺序进行创建和定义：

```text
资源配置（Unit Config）──> 资源池（Resource Pool）──> 租户（Tenant）
     定义规格                  组合资源单元              分配给业务

```

#### 说明

资源配置指定的是对应资源单元能够提供的**服务能力**，而不是资源单元的实时负载。详细信息请参见 [租户的资源管理](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616523)。

## 创建不同业务租户

以下示例模拟一个集群同时承载两个业务的场景：为业务 A 创建规格较小的租户 `tenant1`，为业务 B 创建规格较大的租户 `tenant2`，两者共享集群资源但相互隔离。

### 操作步骤

1. 使用 root 用户登录集群的 sys 租户（密码为部署时随机生成的密码，获取方式见上文前提条件）：

   ```shell
   obclient -h127.0.0.1 -uroot@sys -P2881 -p -A oceanbase

   ```
 2. 创建两个资源配置。以下示例分别创建 1C2G 和 2C4G 的资源单元规格，您可根据机器实际配置调整：

   ```sql
   obclient [oceanbase]> CREATE RESOURCE UNIT unit1 MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G';
   obclient [oceanbase]> CREATE RESOURCE UNIT unit2 MAX_CPU=2, MIN_CPU=2, MEMORY_SIZE='4G';

   ```

   命令中的关键参数说明：

   | 参数 | 说明 |
   | --- | --- |
   | `MAX_CPU` | 资源单元能够提供的 CPU 上限。必选参数。 |
   | `MIN_CPU` | 资源单元能够提供的 CPU 下限，默认等于 `MAX_CPU`。 |
   | `MEMORY_SIZE` | 资源单元能够提供的内存规格。必选参数。 |
   | `LOG_DISK_SIZE` | 日志盘空间，默认等于 3 倍内存大小，最小为 2G。 |
   | `MAX_IOPS` / `MIN_IOPS` | 资源单元可提供的 IOPS 上下限，最小值均为 1024，未指定时默认为 `INT64_MAX`。 |
 3. 创建资源池并关联资源配置。单节点集群的 `ZONE_LIST` 为 `('zone1')`：

   ```sql
   obclient [oceanbase]> CREATE RESOURCE POOL pool1 UNIT='unit1', UNIT_NUM=1, ZONE_LIST=('zone1');
   obclient [oceanbase]> CREATE RESOURCE POOL pool2 UNIT='unit2', UNIT_NUM=1, ZONE_LIST=('zone1');

   ```

   | 参数 | 说明 |
   | --- | --- |
   | `UNIT` | 为资源池指定的资源配置，资源池下的每个资源单元均使用该规格。 |
   | `UNIT_NUM` | 资源池在 `ZONE_LIST` 内每个 Zone 上创建的资源单元个数。 |
   | `ZONE_LIST` | 资源池的使用范围，指定在哪些 Zone 上创建资源单元。 |
 4. 分别创建租户 `tenant1` 和 `tenant2`，并关联对应的资源池：

   ```sql
   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS tenant1 CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool1') SET ob_tcp_invited_nodes='%';

   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS tenant2 CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool2') SET ob_tcp_invited_nodes='%';

   ```

   | 参数 | 说明 |
   | --- | --- |
   | `CHARSET` | 租户的字符集，本例设置为 `utf8mb4`。 |
   | `PRIMARY_ZONE` | 租户的 Leader 副本优先分布的 Zone。 |
   | `RESOURCE_POOL_LIST` | 租户关联的资源池列表。 |
   | `ob_tcp_invited_nodes` | 租户访问白名单，`'%'` 表示任意 IP 均可访问，后期可修改。 |
 5. 确认租户创建成功：

   ```sql
   obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, STATUS, TENANT_ROLE
                       FROM DBA_OB_TENANTS WHERE TENANT_TYPE = 'USER';

   ```

   返回结果示例如下，`tenant1` 和 `tenant2` 的 `STATUS` 均为 `NORMAL`，表示租户创建成功：

   ```shell
   +-----------+-------------+-------------+--------+-------------+
   | TENANT_ID | TENANT_NAME | TENANT_TYPE | STATUS | TENANT_ROLE |
   +-----------+-------------+-------------+--------+-------------+
   |         1 | sys         | SYS         | NORMAL | PRIMARY     |
   |      1002 | tenant1     | USER        | NORMAL | PRIMARY     |
   |      1004 | tenant2     | USER        | NORMAL | PRIMARY     |
   +-----------+-------------+-------------+--------+-------------+
   3 rows in set

   ```

   其中 `TENANT_ID` 等编号由系统自动分配，因环境而异。每个用户租户创建时，系统还会自动创建一个 `META$` 开头的内部租户（`TENANT_TYPE` 为 `META`），用于管理租户元数据，使用 `SELECT * FROM DBA_OB_TENANTS;` 查询全量信息时可见，无需关注。
 6. 使用 root 用户登录 `tenant1`，新创建的租户 root 用户默认密码为空，提示输入密码时直接回车即可：

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

   ```

   登录后执行 `SHOW DATABASES;`，可以看到新租户拥有独立的数据库列表：

   ```shell
   +--------------------+
   | Database           |
   +--------------------+
   | information_schema |
   | mysql              |
   | oceanbase          |
   | test               |
   +--------------------+
   4 rows in set

   ```

   与 `sys` 租户类似，`tenant1` 内也有 `information_schema`、`mysql`、`oceanbase` 三个系统库，用于存放数据库的系统信息和元数据，请勿在其中存储业务数据。

#### 注意

- 创建资源池需要保证有足够的资源剩余。如果资源不足，可将已有租户的资源规格调小（参见本文[在线调整租户资源规格](#在线调整租户资源规格)），或删除不再使用的租户释放资源。删除租户使用 `DROP TENANT` 语句，且租户下的数据库和表会同时被删除，详细信息请参见 [DROP TENANT](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616565)。
 - 系统在创建租户时会默认为 Meta 租户预留资源，各项资源从用户租户的资源中扣除，因此租户实际可用资源会略小于配置值，通过视图查询到的实际生效额度低于 `MEMORY_SIZE` 配置值属正常现象。
 - 本文示例针对单节点集群，只能创建单副本租户。如果您的集群有 3 个节点，`ZONE_LIST` 的值应为 `('zone1','zone2','zone3')`，`PRIMARY_ZONE` 可设置为 `'zone1;zone2;zone3'`。

## 体验租户间隔离

多租户架构下，租户与租户之间的数据、权限完全隔离：OceanBase 不允许跨租户的数据访问，每个租户拥有独立的用户体系。本节通过两组操作直观验证隔离性。

### 数据隔离

1. 在 `tenant1` 中创建一张测试表并插入数据：

   ```

   ```sql
   obclient [test]> CREATE TABLE business_a_order (id INT PRIMARY KEY, item VARCHAR(50), amount DECIMAL(10,2));
   Query OK, 0 rows affected

   obclient [test]> INSERT INTO business_a_order VALUES (1, 'keyboard', 149.00);
   Query OK, 1 row affected

   obclient [test]> SHOW TABLES;
   +------------------+
   | Tables_in_test   |
   +------------------+
   | business_a_order |
   +------------------+
   1 row in set

   ```
 2. 使用 root 用户登录 `tenant2`，查看 `test` 库中的表：

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

   ```

   ```sql
   obclient [test]> SHOW TABLES;
   Empty set

   ```

   `tenant2` 中看不到 `tenant1` 创建的任何表。两个租户拥有各自独立的 `test` 库，数据完全隔离。

### 权限隔离

每个租户拥有独立的用户体系，一个租户中创建的用户无法登录另一个租户。

1. 在 `tenant1` 中创建业务用户：

   ```sql
   obclient [test]> CREATE USER app_user IDENTIFIED BY '******';
   Query OK, 0 rows affected

   ```
 2. 尝试使用 `app_user` 连接 `tenant2`（提示输入密码时输入 `app_user` 的密码）：

   ```shell
   obclient -h127.0.0.1 -uapp_user@tenant2 -P2881 -p -A test
   Enter password:
   ERROR 1045 (42000): Access denied for user 'app_user'@'xxx.xxx.xxx.xxx' (using password: NO)

   ```

   连接失败并报 `ERROR 1045 Access denied`，这是因为 `app_user` 只存在于 `tenant1` 的用户体系中，`tenant2` 无法识别该用户。报错末尾的 `using password: NO` 表示该用户在 `tenant2` 中不存在，并非提示您未输入密码。同理，`tenant1` 的 root 用户与 `tenant2` 的 root 用户也是两个完全独立的账号。

#### 说明

在数据安全方面，OceanBase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险；在资源使用方面，OceanBase 表现为租户"独占"其资源配额。详细信息请参见 [多租户架构概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615920)。

## 在线调整租户资源规格

OceanBase 数据库可以灵活地对租户的 CPU、内存资源进行调整，并且**在线生效、对业务透明**。修改租户所占用的 CPU、内存大小，仅需调整租户所对应的资源配置，不需要对资源池或租户进行调整。

### 操作步骤

1. 在 sys 租户中查看当前资源配置：

   ```sql
   obclient [oceanbase]> SELECT UNIT_CONFIG_ID, NAME, MAX_CPU, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE
                       FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE NAME IN ('unit1', 'unit2');

   ```

   返回结果示例如下：

   ```shell
   +----------------+-------+---------+---------+-------------+---------------+
   | UNIT_CONFIG_ID | NAME  | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE |
   +----------------+-------+---------+---------+-------------+---------------+
   |           1006 | unit1 |       1 |       1 |  2147483648 |    6442450944 |
   |           1007 | unit2 |       2 |       2 |  4294967296 |   12884901888 |
   +----------------+-------+---------+---------+-------------+---------------+
   2 rows in set

   ```

   查询结果显示，`unit1` 资源单元的 CPU、内存分别为 1C、2G，日志盘空间为 6G（默认等于 3 倍内存大小）。`UNIT_CONFIG_ID` 为系统自动分配的编号，因环境而异；`MEMORY_SIZE`、`LOG_DISK_SIZE` 的单位为字节，可按 1G = 1073741824 字节换算。
 2. 将 `unit1` 的规格在线调整为 2C、4G，模拟业务 A 的资源扩容：

   ```sql
   obclient [oceanbase]> ALTER RESOURCE UNIT unit1 MAX_CPU=2, MIN_CPU=2, MEMORY_SIZE='4G';
   Query OK, 0 rows affected

   ```
 3. 再次查询资源配置，确认调整已生效（重复步骤 1 中的查询语句即可）：

   ```

   返回结果中 `unit1` 的 `MAX_CPU` 和 `MIN_CPU` 已变为 `2`，`MEMORY_SIZE` 已变为 `4294967296`（即 4G）。`LOG_DISK_SIZE` 保持不变，`ALTER` 语句仅调整显式指定的选项，如需同时调整日志盘规格，可在语句中一并指定 `LOG_DISK_SIZE`：

   ```shell
   +----------------+-------+---------+---------+-------------+---------------+
   | UNIT_CONFIG_ID | NAME  | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE |
   +----------------+-------+---------+---------+-------------+---------------+
   |           1006 | unit1 |       2 |       2 |  4294967296 |    6442450944 |
   |           1007 | unit2 |       2 |       2 |  4294967296 |   12884901888 |
   +----------------+-------+---------+---------+-------------+---------------+
   2 rows in set

   ```
 4. 通过 `GV$OB_UNITS` 视图查看资源单元在节点上的分布及实际生效情况：

   ```sql
   obclient [oceanbase]> SELECT SVR_IP, UNIT_ID, TENANT_ID, ZONE, MAX_CPU, MIN_CPU, MEMORY_SIZE, STATUS
                       FROM oceanbase.GV$OB_UNITS;

   ```

   返回结果示例如下（`10.10.10.1` 为示例 IP，实际显示为您的本机 IP；`UNIT_ID`、`TENANT_ID` 因环境而异，可与前文“确认租户创建成功”步骤中查询到的 `TENANT_ID` 对应）：

   ```shell
   +------------+---------+-----------+-------+---------+---------+-------------+--------+
   | SVR_IP     | UNIT_ID | TENANT_ID | ZONE  | MAX_CPU | MIN_CPU | MEMORY_SIZE | STATUS |
   +------------+---------+-----------+-------+---------+---------+-------------+--------+
   | 10.10.10.1 |       1 |         1 | zone1 |       2 |       2 |  1073741824 | NORMAL |
   | 10.10.10.1 |    1002 |      1001 | zone1 |    NULL |    NULL |  1073741824 | NORMAL |
   | 10.10.10.1 |    1002 |      1002 | zone1 |       2 |       2 |  3221225472 | NORMAL |
   | 10.10.10.1 |    1003 |      1003 | zone1 |    NULL |    NULL |  1073741824 | NORMAL |
   | 10.10.10.1 |    1003 |      1004 | zone1 |       2 |       2 |  3221225472 | NORMAL |
   +------------+---------+-----------+-------+---------+---------+-------------+--------+
   5 rows in set

   ```

   返回结果中，每个资源单元对应一行记录：`TENANT_ID` 为 `1` 的行是 `sys` 租户的资源单元；`MAX_CPU` 为 `NULL` 的行是内部 Meta 租户的资源记录；其余两行分别是 `tenant1` 和 `tenant2` 的资源单元，`STATUS` 为 `NORMAL` 表示资源单元状态正常。视图中的 `MEMORY_SIZE` 为扣除系统预留后的实际生效额度，会小于配置值（例如 4G 规格显示为 3221225472，约 3G）。

#### 说明

- `ALTER RESOURCE UNIT` 语句执行成功后，`DBA_OB_UNIT_CONFIGS` 中的配置值会立即更新；资源单元实际生效的过程在后台异步完成，通常在数十秒内完成。若通过 `GV$OB_UNITS` 视图查询到的仍是旧值，请稍候重试。
 - 资源调整在线完成，无需数据迁移或重启，对业务无感知。
 - 除调大规格外，也支持使用相同方法调小规格，实现租户资源的缩容。调整时请确保目标规格满足业务负载需要。
 - 通过查看 `DBA_OB_UNITS` 视图，还可以获取资源单元、资源池、租户在集群里的对应关系及 CPU、内存信息。

### 资源变更方式对比

除直接修改资源配置外，OceanBase 还支持通过切换资源配置、调整 `UNIT_NUM`、变更 `ZONE_LIST` 等方式进行租户资源变更，分别适用于不同的扩缩容场景（后两种适用于多 Zone、多节点集群，单节点环境无法演示）：

| 变更方式 | 语句 | 适用场景 |
| --- | --- | --- |
| 修改资源配置 | `ALTER RESOURCE UNIT unit1 MAX_CPU=2;` | 直接调整规格，在线生效 |
| 切换资源配置 | `ALTER RESOURCE POOL pool1 UNIT='unit3';` | 资源池整体切换到另一套规格 |
| 调整 UNIT_NUM | `ALTER RESOURCE POOL pool1 UNIT_NUM=2;` | 增减每个 Zone 内的资源单元数量，增大时需保证目标 Zone 内有可用节点，减小时需配合 `DELETE UNIT` 指定要删除的资源单元 |
| 变更 ZONE_LIST | `ALTER RESOURCE POOL pool1 ZONE_LIST=('zone1','zone2');` | 扩大或缩小 Zone 维度的使用范围 |

## 压测观察租户性能

完成前两节的操作后，`tenant1`（1C2G）和 `tenant2`（2C4G）两个业务租户已就绪。本节使用 sysbench 对租户执行标准点查压测，验证新租户可正常承载业务流量，并结合结果理解 OceanBase 的资源隔离逻辑。

### 操作步骤

1. 对小规格租户 `tenant1` 发起点查压测（如已按上一节将 `unit1` 调整为 2C4G，可先执行 `ALTER RESOURCE UNIT unit1 MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G';` 调回）：

   ```shell
   obd test sysbench demo --tenant=tenant1 --script-name=oltp_point_select.lua --table-size=100000 --threads=16 --rand-type=uniform

   ```

   首次执行时，`obd` 会自动完成测试数据生成、数据加载和压测执行，结束后输出 QPS、延迟等统计结果，记录其中的 QPS 和 95% 延迟。
 2. 对大规格租户 `tenant2`（2C4G）执行完全相同参数的压测：

   ```shell
   obd test sysbench demo --tenant=tenant2 --script-name=oltp_point_select.lua --table-size=100000 --threads=16 --rand-type=uniform

   ```
 3. 对比两轮测试结果，重点确认：

      - 两轮压测均正常结束并输出统计结果，说明两个租户均可独立承载业务流量；
      - 压测数据在各租户中独立生成，`tenant1` 的压测不会在 `tenant2` 中留下数据。

### 结果解读

两轮压测的 QPS 数值因机器规格、数据量、并发参数不同而差异较大，无需关注绝对值，重点观察以下现象：

| 观察项 | 预期现象 | 说明 |
| --- | --- | --- |
| **压测执行** | 两轮压测均正常结束，无报错 | 新租户可正常承载业务流量 |
| **两轮 QPS 对比** | 差异可能不明显 | `MAX_CPU` 是资源上限而非保证值。集群 CPU 资源富余时，租户实际可使用的 CPU 可能超过其配额，此时不同规格的租户测出的 QPS 相差不大属正常现象 |
| **多租户同时负载** | 压测 `tenant2` 时 `tenant1` 中的查询响应时间基本不变 | 资源配额的隔离效果主要体现在多个租户同时争抢资源时：高规格租户获得更多算力，低规格租户的业务不受挤占 |

#### 说明

- `obd test sysbench` 会自动完成测试数据生成、数据加载和压测执行，压测数据在各租户中独立生成，互不影响。命令参数的详细说明请参见 [体验高并发 OLTP 场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140970)。
 - 本文示例规格较小，测试结果主要用于验证租户可用性与资源隔离机制，不代表 OceanBase 数据库的生产级性能。官方性能测试报告可参见 [OceanBase Sysbench 性能测试报告](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000218152)（V4.2.1 版本测试数据）。
 - 如需观察租户间的资源隔离效果，可在压测一个租户的同时在另一个租户中执行点查，观察其响应时间（显示在查询结果后，如 `1 row in set (0.00 sec)`）是否保持稳定。

## 下一步

完成本文的多租户与资源隔离体验后，您可以继续以下探索之旅：

1. **体验高可用与故障切换**：了解 OceanBase 的副本、Zone、Leader/Follower 等核心概念，观察副本与 Leader 分布，体验故障场景下的服务连续性，参见 [体验高可用与故障切换](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140974)。
 2. **体验水平扩展与弹性伸缩**：探索计算、存储和租户资源层面的扩展能力，观察扩容前后的资源变化与业务容量影响，参见 [体验水平扩展与弹性伸缩](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140975)。
 3. **体验租户内资源隔离**：在同一租户内通过资源组隔离 TP 与 AP 负载，参见 [体验 HTAP 混合负载场景](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140971)。

## 相关文档

- 多租户特性的完整体验流程请参见 [体验多租户特性](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615142)。
 - 多租户架构的基本概念请参见 [多租户架构概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615920)。
 - 租户资源管理（资源配置、资源池、资源单元）的详细说明请参见 [租户的资源管理](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616523)。
 - 查看租户资源配置的方法请参见 [查看资源规格](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616153)。
 - 删除租户的语法说明请参见 [DROP TENANT](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616565)。
 - 租户内资源隔离（资源组）的配置方法请参见 [配置租户内资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006619072)。
 - OBD 测试命令的详细参数请参见 [测试命令组](https://www.oceanbase.com/docs/common-obd-cn-1000000005150935)。

 上一篇 下一篇 ![有帮助](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) 咨询热线