OceanBase 4.x 架构师知识库

OceanBase 4.x 采用 Shared-Nothing 分布式集群架构。整个集群由多个 OBServer 节点组成，每个节点独立拥有自身的 CPU、内存、磁盘等资源，节点之间不共享任何硬件资源，通过网络进行通信与协调。所有 OBServer 节点在功能上完全对等，每个节点都包含完整的 SQL 引擎、存储引擎、事务引擎以及 Paxos 副本管理能力，无单点瓶颈。

核心设计理念

Shared-Nothing 是分布式数据库实现高可扩展性、高可用性和低成本的基础。相比 Shared-Disk（如 Oracle RAC）或 Shared-Everything（如单机数据库），OceanBase 的设计避免了共享存储带来的锁竞争和缓存一致性开销，并允许系统在通用 X86/ARM 服务器上线性扩展。

数据分片：Tablet

OceanBase 4.x 将数据进一步细粒度分片，最小物理存储单元称为 Tablet。每个非分区表对应一个 Tablet，每个分区表的一个分区也对应一个 Tablet。Tablet 是数据迁移、负载均衡和故障恢复的最小单位。Tablet 的大小通常建议控制在约 2GB 左右（基于运维经验的推荐值，并非绝对限制）。RootService 会根据 Tablet 上的请求负载（如 CPU 耗时、IO 次数、网络流量）动态调度 Tablet 在节点间迁移，避免形成热点。

多副本与 Paxos 角色

每个 Tablet 通常维护 3 个或更多副本（数量由租户的 replica_num 决定）。每个副本承担不同的 Paxos 角色：

• Leader 副本： 提供强一致性读写服务，所有写请求必须路由到 Leader。Leader 负责发起 Paxos 日志同步。
• Follower 副本： 参与 Paxos 日志投票，可提供弱一致性读（通过 READ_CONSISTENCY = WEAK 配置）。

Leader 的选举和切换完全由 Paxos 协议自动完成，客户端无感知。切换时间通常在 2～8 秒内。

负载均衡与弹性伸缩

OceanBase 集群内置了 RootService 作为总控服务，负责：

• Unit 调度： 资源单元（Unit）在节点间的分布均衡，保证各节点 CPU/内存利用率相近。
• Tablet 负载均衡： 监控每个 Tablet 的请求负载，自动将高负载 Tablet 的 Leader 副本迁移到低负载节点。
• 扩容/缩容： 添加新节点后，系统自动将部分 Unit 或 Tablet 迁移到新节点，实现数据再平衡；删除节点前，数据会自动迁移走，不丢失数据。

-- 查看当前集群中的节点与资源使用情况
        SELECT * FROM oceanbase.DBA_OB_SERVERS;

        -- 查看各节点的 Tablet 数量分布（使用 DBA_OB_TABLET_REPLICAS 视图）
        SELECT SVR_IP, COUNT(*) AS tablet_count 
        FROM oceanbase.DBA_OB_TABLET_REPLICAS 
        GROUP BY SVR_IP;

与传统架构对比

4.x 架构优化亮点

• 日志流（Log Stream）：将多个 Tablet 的日志合并为一个 Paxos 日志流，减少网络开销和存储冗余，大幅提升写入性能。
• 元数据服务独立化：系统租户与 Meta 租户分离，各租户元数据管理不再相互干扰。
• 动态线程模型：工作线程与租户 CPU 配额解耦，租户间资源隔离更精确。

OceanBase 原生支持多租户架构，允许在一个集群内创建多个相互隔离的数据库“实例”（即租户）。每个租户拥有独立的资源（CPU、内存、IOPS）、数据和系统变量，租户之间完全隔离，互不影响。这种架构使得 OceanBase 能够以极低的成本为多个业务或用户提供数据库服务，同时保证安全性和性能。

多租户核心概念

多租户的实现基于三个核心抽象：资源单元（Unit）、资源池（Resource Pool） 和 租户（Tenant）。

-- 创建资源单元配置
        CREATE RESOURCE UNIT unit1
            MAX_CPU=8, MIN_CPU=4,
            MEMORY_SIZE='32G',
            MAX_IOPS=128000, MIN_IOPS=128000,
            LOG_DISK_SIZE='2T';

-- 创建资源池，分布在三个 Zone，每个 Zone 一个 Unit
        CREATE RESOURCE POOL pool1
            UNIT='unit1',
            UNIT_NUM=1,          -- 每个 Zone 内 Unit 的数量
            ZONE_LIST=('zone1', 'zone2', 'zone3');

-- 创建 MySQL 兼容模式的租户
        CREATE TENANT tenant_mysql
            CHARSET='utf8mb4',
            ZONE_LIST=('zone1','zone2','zone3'),
            PRIMARY_ZONE='zone1;zone2,zone3',  -- Leader 优先分布在 zone1
            RESOURCE_POOL_LIST=('pool1'),
            SET ob_tcp_invited_nodes='%';

租户类型

OceanBase 4.x 集群中包含以下三种租户[reference:4]：

• 系统租户（sys tenant）：ID 为 1，是集群内置的管理员租户，拥有集群管理的最高权限。系统租户负责集群的元数据管理、资源调度、备份恢复等全局操作。系统租户是单点写入，不支持水平扩缩容[reference:5]。
• 普通租户（user tenant）：业务租户，由用户创建，运行具体应用的数据。每个普通租户可配置为 MySQL 或 Oracle 兼容模式。
• Meta 租户（meta tenant）：自 4.x 版本引入，每个用户租户会自动创建对应的 Meta 租户（生命周期与用户租户一致），用于存储该租户的私有元数据，从而减轻系统租户的负担，增强资源隔离效果[reference:6][reference:7]。租户 ID 规则：偶数表示用户租户，奇数表示 Meta 租户[reference:8]。

资源隔离机制

OceanBase 通过多级资源隔离保证租户之间不会相互干扰：

元数据隔离

除了资源隔离，OceanBase 还实现了元数据的租户级别隔离：

• 每个租户拥有独立的系统表（如 __all_table、__all_column 等），通过租户 ID 前缀区分。
• 系统租户可以查看所有租户的元数据，但普通租户只能看到自己的对象。
• DDL 操作（如 CREATE TABLE）不会阻塞其他租户的元数据查询。

4.x 多租户优化亮点

• Meta 租户独立： 每个普通租户创建时自动生成一个对应的 Meta 租户，专用于存储其元数据、日志流等私有数据，避免系统租户成为元数据瓶颈[reference:11]。
• 更精细的 CPU 隔离： 支持 cgroup 绑定，减少了 CPU 争抢导致的性能抖动。需注意 OceanBase 4.x 依赖 cgroup v1 版本，cgroup v2 环境下隔离功能可能失效[reference:12]。
• 租户克隆： 支持通过 CREATE TENANT new_tenant FROM source_tenant ... 语法快速克隆现有租户（第 10 章详述）[reference:13]。
• 租户参数模板： 可以使用预定义的参数模板快速创建标准租户。
• 内存不再超卖： 从 V4.0.0.0 开始，OceanBase 不再支持内存超卖，确保租户内存分配的确定性[reference:14]。

租户创建最佳实践

-- 查看集群中所有租户
        SELECT tenant_id, tenant_name, tenant_type, primary_zone FROM oceanbase.DBA_OB_TENANTS;

        -- 查看租户的资源使用情况（注意视图名从 V4.0.0 起由 GV$MEMORY 改为 GV$OB_MEMORY）
        SELECT tenant_id, SUM(hold)/1024/1024/1024 AS hold_gb
        FROM oceanbase.GV$OB_MEMORY
        GROUP BY tenant_id;

Zone 是 OceanBase 实现高可用和容灾的核心逻辑概念。一个 OceanBase 集群由若干个 Zone 组成，每个 Zone 代表一组具有相似容灾属性的节点集合。通过将数据副本分布在不同的 Zone 中，OceanBase 能够容忍单节点、单机房甚至城市级别的故障，实现金融级的高可用性。

Zone 的定义与属性

Zone 是对节点进行管理的容器，从物理层面讲，一个 Zone 通常对应一个独立的物理部署单元，可以是一个数据中心（IDC）、云上的一个可用区，或者一个单独的机架（Rack）。每个 Zone 具有两个重要属性：

• Region（地域）：通常指 Zone 所在的城市或地理区域，用于支持跨地域容灾。
• IDC（机房）：指 Zone 所在的物理机房标识，用于同城多机房部署场景下的就近访问优化。

通过合理配置 Zone 的 Region 和 IDC 属性，集群内的自动容灾处理和优化策略能够更好地工作。

-- 查看集群中所有 Zone 的信息
        SELECT ZONE, STATUS, IDC, REGION, TYPE FROM oceanbase.DBA_OB_ZONES;

        -- 修改 Zone 的 Region 和 IDC 属性
        ALTER SYSTEM ALTER ZONE zone1 SET REGION='hangzhou', IDC='HZ0';

OceanBase 集群支持多种部署模式，可以满足不同级别的高可用和容灾需求。

多地域高可用部署方案

OceanBase 支持 IDC、同城、跨城级别的高可用和容灾，提供多种部署方案以满足不同业务需求[reference:7]：

基于 Paxos 的高可用实现

OceanBase 通过 Paxos 协议保证副本间数据强一致性，实现故障自动切换[reference:13]：

• 多数派（Majority）机制：每次事务提交需要获得半数以上副本的确认。例如在三副本集群中，至少需要 2 个副本确认才能提交，这保证了单副本故障时集群仍然可用[reference:14]。
• 自动故障切换：当 Leader 副本所在节点或 Zone 发生故障时，Follower 副本会自动发起选举，通常在 8 秒内完成 Leader 切换，应用无感知[reference:15]。
• 数据零丢失（RPO=0）：事务日志在多数派副本持久化后才返回成功，任何单个副本故障不会造成数据丢失[reference:16]。
• 动态扩缩容：当集群容灾需求变化时，可以增加或减少 Zone 的数量。例如将三副本扩容为五副本，通过增加 Zone4 和 Zone5，再部署新的数据副本来提升系统可用性[reference:17]。

主备租户与角色切换

OceanBase 支持租户级别的主备容灾。通过主备租户特性，可以在不同集群间建立主备关系，实现跨集群的容灾能力。

• 主租户（PRIMARY）：正常创建的业务租户，提供完整的读写服务[reference:18]。
• 备租户（STANDBY）：通过物理备库特性创建的租户，通过日志同步从主租户接收数据变更。OceanBase V4.2.0 起，主备租户之间采用异步日志同步的方式[reference:19]。

租户角色可通过两种操作动态改变：

• Switchover（无损切换）：按计划执行的角色切换，主备租户交换角色，整个过程保证数据无损（RPO=0），通常在秒级完成[reference:20]。
• Failover（容灾切换）：当主租户发生不可恢复故障时执行，将备租户切换为新主租户。此操作在切换前建议使用 VERIFY 子句进行预检查，存在毫秒级数据丢失风险（取决于复制延迟）[reference:21]。

-- 执行 Switchover（在 primary 租户所在集群执行）
        ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant1;

        -- 执行 Failover 预检查
        ALTER SYSTEM ACTIVATE STANDBY TENANT = tenant1 VERIFY;

        -- 执行 Failover
        ALTER SYSTEM ACTIVATE STANDBY TENANT = tenant1;

仲裁服务（Arbitration Service）

OceanBase 数据库企业版从 V4.1.0 版本开始引入仲裁服务，这是一种基于 Paxos 多副本容灾方案提出的新型高可用方案。仲裁服务独立于 OceanBase 集群部署，是一个以特殊模式启动的轻量级 observer 进程，但社区版暂不支持此功能[reference:22]。

仲裁成员具备以下核心特征：

• 仅参与选举和成员变更投票：参与 Leader 选举、Paxos Prepare 以及成员组变更投票，但不参与日志多数派投票（Paxos Accept）[reference:23]。
• 无状态设计：不存储日志，无 MemTable 和 SSTable，资源（带宽/内存/磁盘/CPU）开销极小[reference:24]。
• 不能当选 Leader：仲裁成员无法被选举为 Leader 提供服务[reference:25]。

仲裁方案的核心价值在于：

• 解决了两地三中心场景下，同城副本故障时业务响应时间（RT）变大的问题[reference:26]。
• 降低了跨城带宽开销，并将第三机房的成本降到极低[reference:27]。
• 当半数以上全功能副本故障时，仲裁服务会自动触发降级以恢复服务，且保证 RPO=0；故障副本恢复后自动升级回原始成员列表[reference:28]。

Zone 与多地域高可用运维管理

日常运维中，可以通过以下命令管理和监控 Zone 状态：

-- 查看 Zone 分布和状态
        SELECT * FROM oceanbase.DBA_OB_ZONES;

        -- 停止 Zone（停止后该 Zone 不再参与服务）
        ALTER SYSTEM STOP ZONE zone2;

        -- 启动 Zone
        ALTER SYSTEM START ZONE zone2;

        -- 隔离 Zone（用于故障应急）
        ALTER SYSTEM ISOLATE ZONE zone2;

        -- 强制停止 Zone（不检查日志同步状态）
        ALTER SYSTEM FORCE STOP ZONE zone2;

当需要对 Leader 副本分布进行调整时，可以通过修改租户的 PRIMARY_ZONE 属性实现平滑切主：

-- 修改租户的优先 Leader Zone，实现 Leader 集中或分散
        ALTER TENANT tenant1 SET PRIMARY_ZONE = 'zone1;zone2,zone3';

4.x 版本高可用优化亮点

• 仲裁服务引入：V4.1.0 起支持仲裁服务，可在 2F1A（两副本加仲裁）部署模式下实现低成本的高可用，RPO=0[reference:32]。
• 日志流架构优化：以日志流作为 Paxos 复制的基本单元，取代旧版本中以分区为单位的模式，大幅降低海量分区带来的资源开销[reference:33]。
• RTO 持续优化：通过并行 Paxos 和动态 Leader 切换，故障恢复时间从早前版本的 30 秒降低到 8 秒以内[reference:34]。
• 更灵活的扩缩容：支持在线增减 Zone 和 OBServer 节点，集群扩容缩容期间业务不中断。

OBProxy（OceanBase Database Proxy，也称 ODP）是 OceanBase 集群的轻量级反向代理层。它作为客户端与 OBServer 节点之间的桥梁，负责将 SQL 请求路由到正确的 OBServer 节点，同时提供连接池管理、负载均衡、黑名单过滤、读写分离等高级功能。OBProxy 本身无状态，支持水平扩展，是 OceanBase 高可用架构中不可或缺的接入层组件。

基本工作流程

当客户端通过 OBProxy 发送 SQL 请求时，OBProxy 执行以下核心步骤：

1. 解析 SQL 路由信息：从 SQL 文本中提取路由所需的关键信息（如分区键值、表名等）。
2. 查询 Location Cache：根据解析结果查找目标分区所在 OBServer 节点的 IP 和端口。
3. 选择目标 OBServer：结合路由策略（如 LDC 就近访问、读写分离等），决定最终转发的节点。
4. 转发请求并缓存结果：将请求发送给选中的 OBServer，并将路由结果缓存到本地 Location Cache 中，加速后续请求。

三种路由计划

OBProxy 根据 SQL 访问的数据分布情况，生成三种不同类型的路由计划。目标是将 Remote 和 Distributed 计划尽量转化为 Local 计划，减少跨节点网络开销。

-- 通过 SQL Audit 查看 SQL 的 plan_type 分布（request_time 为微秒级）
        SELECT plan_type, COUNT(*) AS cnt 
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000
        GROUP BY plan_type;

        -- plan_type 含义：1=Local, 2=Remote, 3=Distribute, 0=无计划（如 COMMIT）

分区表路由计算

对于分区表，OBProxy 会根据 SQL 中的条件计算目标分区 ID（Partition ID），具体规则如下：

• 等值条件：对于 WHERE partition_key = constant，OBProxy 直接计算常量对应的分区。
• INSERT 语句：根据插入行的分区键值计算目标分区。
• 范围条件：如果条件为 partition_key > 100，OBProxy 无法确定唯一分区，将生成 Distributed 计划或发送到所有分区。

如果 OBProxy 无法从 SQL 中计算出分区 ID（例如分区键使用了函数或隐式类型转换），则无法拉取准确的路由。可通过 obproxy.log 中的关键字 "calculate partition id" 排查路由失败的原因。

Location Cache 与内部依赖表

OBProxy 在内存中维护了一个 Location Cache，用于缓存分区与 OBServer 节点的映射关系。该缓存通过定期查询 OBServer 的内部表来刷新：

• __all_virtual_proxy_schema：用于保存分区与其所在机器的对应关系信息，也有 Partition 的部分相关信息[reference:17]。
• __all_virtual_proxy_partition_info：保存分区表相关分区信息[reference:18]。

OBProxy 启动时会从配置的 RootService 地址获取集群拓扑，后续按需（首次访问某分区时）或定期（默认 15 秒至 30 秒）拉取最新的路由信息。当发生 Leader 切换或副本迁移时，Location Cache 会自动失效并重新拉取。

黑名单与故障节点自动摘除

OBProxy 会主动检测后端 OBServer 的健康状态。当一个 OBServer 节点在 congestion_fail_window（默认 120 秒）内错误次数超过 congestion_failure_threshold 配置的值时，OBProxy 会将该节点加入黑名单[reference:20]。

黑名单机制有效避免了因个别 OBServer 故障导致的请求堆积和重试风暴。可通过 OCP 或 SHOW PROXYCONFIG LIKE '%congestion%' 查看相关参数。

连接管理与会话保持

OBProxy 内部维护了到 OBServer 的连接池，以减少频繁建立连接的开销：

• 客户端连接：每个客户端与 OBProxy 建立一个 TCP 连接。
• 后端连接：OBProxy 根据租户、数据库等维度复用到 OBServer 的连接，连接池大小由 max_connections 等参数控制。
• 会话状态保持：由于 OBProxy 是无状态的[reference:21]，客户端 Session 状态（如事务、临时表、用户变量）实际保存在 OBServer 上。OBProxy 通过版本号机制同步不同后端连接上的 Session 状态，保证功能正确性[reference:22]。

路由调优最佳实践

-- 查看当前 OBProxy 的路由信息（通过连接到 OBProxy 执行）
        SHOW PROXYROUTE;

        -- 清理指定 OBServer 的路由缓存（强制重新拉取）
        ALTER SYSTEM FLUSH LOCATION CACHE TENANT = 'tenant1' SERVER = '192.168.1.1:2882';

        -- 查看 OBProxy 黑名单（需登录到 OBProxy 主机查看日志或 OCP）

逻辑数据中心（Logical Data Center，LDC）路由是 OceanBase 为解决多地多中心部署时跨地域路由延迟问题而设计的核心机制。通过在集群 Zone 上设置 Region（地域）和 IDC（机房）属性，并在 OBProxy 上指定其所属的 IDC，系统能够将数据请求优先路由到同机房、同地域的副本，从而大幅降低网络延迟，提升数据库整体性能。

核心概念

LDC 路由机制的实现依赖于集群与 OBProxy 的两层配置：

• Region（地域）： Zone 所在的地域信息，通常设置为城市名（大小写敏感），例如 "SHANGHAI"、"HANGZHOU"。
• IDC（机房/数据中心）：Zone 所处的具体机房信息，通常设置为机房名（小写），例如 "zue"、"ztg"。
• proxy_idc_name：OBProxy 进程启动时指定的参数，用于标识 OBProxy 所属的逻辑数据中心，需要与集群中某个 Zone 的 IDC 属性相对应。

一个 OceanBase 集群包含若干个 Region，每个 Region 包含若干个 Zone，每个 Zone 对应一个 IDC 属性。当 OBProxy 接收到请求时，它通过比对自身的 proxy_idc_name 与各 OBServer 的 IDC/Region 属性，来决定路由的优先级。

LDC 路由优先级

当数据请求到达 OBProxy 时，OBProxy 会严格按照以下优先级顺序选取目标副本进行路由转发：

1. 选取本机房（同 IDC）不在合并中的副本。
2. 选取同 Region 其他机房不在合并中的副本。
3. 选取本机房（同 IDC）正在进行合并的副本。
4. 选取同 Region 其他机房正在进行合并的副本。
5. 随机选取跨 Region（异地）且不在合并中的副本。
6. 随机选取跨 Region（异地）且正在进行合并的副本。

配置 LDC 路由的完整流程

启用 LDC 路由需要完成以下三个核心步骤[reference:2][reference:3]：

1. 配置 OceanBase 集群的 LDC

使用 root@sys 用户登录集群，为每个 Zone 设置 Region 和 IDC 属性。

-- 登录 sys 租户后执行
        ALTER SYSTEM MODIFY zone "zone1" SET region = "SHANGHAI";
        ALTER SYSTEM MODIFY zone "zone1" SET idc = "zue";

        ALTER SYSTEM MODIFY zone "zone2" SET region = "SHANGHAI";
        ALTER SYSTEM MODIFY zone "zone2" SET idc = "zue";

        ALTER SYSTEM MODIFY zone "zone3" SET region = "HANGZHOU";
        ALTER SYSTEM MODIFY zone "zone3" SET idc = "ztg";

参数说明[reference:4]：
- region：Zone 所在的地域信息，通常设置为城市名（大小写敏感）。
- idc：Zone 所处的具体机房信息，通常设置为机房名（小写）。
- zone：待修改的 Zone 名称。
验证配置：通过以下查询确认 LDC 设置是否生效，检查 DBA_OB_ZONES 视图中 REGION 和 IDC 字段的值是否符合预期。

SELECT * FROM oceanbase.DBA_OB_ZONES;

2. 配置 OBProxy（ODP）的 LDC

OBProxy 的 LDC 配置有两种方式[reference:5][reference:6]：

-- 【推荐】方式一：进程启动时通过参数指定（推荐方式）
        cd /opt/taobao/install/obproxy-1.5.5
        ./bin/obproxy -o proxy_idc_name=zue

        -- 方式二：通过 ALTER PROXYCONFIG 动态修改
        obclient> ALTER PROXYCONFIG SET proxy_idc_name = 'zue';

上述示例中，为 OBProxy 配置 LDC 后，如果应用部署在上海 zue 机房，当应用发起弱一致性读时，请求会被优先发往上海机房。

验证配置：通过以下命令确认 OBProxy 的 IDC 配置是否生效。

obclient> SHOW PROXYINFO IDC;

3. 应用配置弱一致性读

LDC 路由机制仅对弱一致性读（Weak Consistency Read）场景生效。通过将读请求配置为弱一致性，请求可以根据 LDC 策略被路由到最优副本，从而实现读写分离或就近读取。OceanBase 提供以下三种配置方式[reference:7]：

-- 方式一：HINT 指定（SQL 级别）
        obclient> SELECT /*+read_consistency(weak)*/ * FROM t1;

        -- 方式二：SESSION 变量（Session 级别）
        obclient> SET @@ob_read_consistency = 'weak';

        -- 方式三：GLOBAL 变量（租户级别，对所有连接生效）
        obclient> SET @@global.ob_read_consistency = 'weak';

有界旧一致性：OceanBase 提供租户级配置项 max_stale_time_for_weak_consistency 来定义弱读可容忍的最大落后时间（默认 5 秒），保证读取的数据不会落后于最新数据超过特定时间[reference:8]。
单调读一致性：通过设置租户级配置项 enable_monotonic_weak_read（默认为 True），可以保证弱一致性读的版本单调性，即客户端不会读到版本回退的数据[reference:9]。

高级路由策略

在 OBProxy 中，除了 LDC 路由，还可以通过 proxy_route_policy 等参数进一步精细化控制路由行为。LDC 路由与路由策略结合使用，可以实现更灵活的路由控制。

• 副本类型优先策略：follower_first（请求优先路由到备副本，所有备副本不可用时才路由到 Leader）和 follower_only（请求仅路由到备副本，无备副本可用时断开连接）等[reference:10]。
• 指定主可用区：proxy_primary_zone_name 参数可强制 OBProxy 仅将请求路由到指定的主可用区[reference:11]。
• 基于权重的负载均衡：将 proxy_route_policy 设置为 WEAKREAD_WEIGHT_LOAD_BALANCE，系统将按照为每个 Zone 设置的权重（通过 weakread_weight_zone 参数配置）来分配弱一致性读请求[reference:12]。

故障排查

OceanBase 数据库从 V4.1.0 版本开始支持仲裁服务，这是一种基于 Paxos 多副本容灾方案提出的新型高可用方案，旨在解决两地三中心场景下同城副本故障时响应时间升高的问题，同时还能有效降低跨城带宽的开销，并将第三机房的成本降到极低。需要注意的是，仲裁服务是 OceanBase 企业版的特有功能，社区版暂不支持。

仲裁服务的特点

仲裁成员具有以下核心特征：

• 仅参与投票，不参与日志多数派：仅在 Leader 选举、Paxos Prepare 以及成员组变更中投票，不参与 Paxos Accept 投票，这是其轻量化的关键。
• 无状态、资源消耗极低：不存储日志，没有 MemTable 或 SSTable，因此对带宽、内存、磁盘和 CPU 的开销极小。
• 不能当选为主提供服务：无法被选举为 Leader 对外提供服务，始终作为从副本（Follower）角色存在，不承载业务读写流量。

核心机制：自动降级与升级

📉 日志流降级（自动降级）

当租户开启仲裁服务后，如果日志同步失败且持续时间达到 arbitration_timeout（默认 5s），仲裁服务会自动执行日志流降级流程，将故障副本从成员列表中删除（但租户的 Locality 不会变化），从而恢复服务，且能做到 RPO = 0。

• 触发条件：仅当故障副本（包括已降级的副本）总数等于全功能副本总数的一半时，仲裁服务才会执行日志流降级。例如，4F1A 部署下：
  • 1 个 F 副本故障（故障 1，总数 4）→ 不满足一半条件，不降级。
  • 2 个 F 副本故障（故障 2，总数 4）→ 满足条件，自动降级。
• 触发异常：包括副本所在的 Server 宕机、被 STOP、被 KILL、网络中断、租户日志盘满，以及长时间故障后的 Rebuild 期间。

-- 查看租户当前的仲裁降级控制超时时间
        SHOW PARAMETERS LIKE 'arbitration_timeout';

        -- 修改租户的日志流降级控制时间（例如调整为 10 秒）
        ALTER SYSTEM SET arbitration_timeout = '10s';

配置说明：
- 租户级配置项 arbitration_timeout 用于设置触发日志流自动降级的控制时间，默认值为 5s，取值范围为 [3s, +∞)。
- 该配置项配置后实时生效，不需要重启 OBServer 节点。
- 如果不希望发生降级，可将其设置为一个较大的值，例如 30d（30 天）。

📈 日志流升级（自动恢复）

如果当前日志流已经处于降级状态，仲裁服务会周期性检测 DEGRADED_LIST 中的副本。如果发现被降级的副本日志同步已恢复并且不存在降级策略中所列出的异常，就会自动执行日志流升级流程，将被降级的副本重新加入成员列表，提供更高的可用性保证。

监控降级状态：通过以下 SQL 判断当前是否存在降级的日志流：

SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE DEGRADED_LIST NOT LIKE '';

如果查询结果中有日志流对应的 DEGRADED_LIST 记录不为空，则表示该日志流发生了降级。

仲裁服务的生命周期管理

🏗️ 1. 部署仲裁服务

# 在独立的服务器上，以仲裁模式启动 observer 进程
        # 需准备相应硬件资源，并确保与 OceanBase 集群网络互通
        # 示例启动命令
        ./bin/observer -p 2882 -P 2882 -z zone_arb -d /data/1/arb_service --appname arb_service -o "arbitration_service=true"

前提条件：
- 仲裁服务独立于 OceanBase 集群部署，需要一台单独的机器，其 CPU/内存/磁盘资源需求较小。
- 版本兼容性：新替换的仲裁服务版本需与 OceanBase 集群的大版本保持一致，以确保兼容性。

➕ 2. 向 OceanBase 集群中添加仲裁服务

仲裁服务部署完成后，需要在 OceanBase 集群中执行添加操作，然后集群内的租户才能使用该仲裁服务。

-- 登录 sys 租户执行
        ALTER SYSTEM ADD ARBITRATION SERVICE "10.xx.xx.3:2882";

        -- 验证仲裁服务是否添加成功
        SELECT * FROM oceanbase.DBA_OB_ARBITRATION_SERVICE;

关键限制：
- 单个 OceanBase 集群最多只能使用一个仲裁服务。
- 仲裁服务目前只支持单机部署。

🔛 3. 为租户开启仲裁服务

仲裁服务以租户为单位启用或关闭。开启前需确认租户的 Locality 为 2F 或 4F（即 2 个或 4 个全功能副本）。开启仲裁服务仅对租户 Locality 中的 F 副本个数有要求，对租户 Locality 中的 R 副本无限制。例如，租户的 Locality 为 F@z1,F@z2 或 F@z1,F@z2,R@z3 均可以开启仲裁服务。

-- 启用租户的仲裁服务（在 sys 租户中执行）
        ALTER TENANT tenant_name ENABLE_ARBITRATION_SERVICE = true;

        -- 停用租户的仲裁服务
        ALTER TENANT tenant_name ENABLE_ARBITRATION_SERVICE = false;

开启前置检查：
- 通过 SELECT * FROM oceanbase.GV$OB_ARBITRATION_SERVICE_STATUS 检查各节点与仲裁服务的通信状态（STATUS 需为 ACTIVE）。只有所有节点均通信正常才可以为租户开启仲裁服务。
- 通过 SELECT * FROM oceanbase.DBA_OB_TENANTS WHERE tenant_name = '...' 查看当前 ARBITRATION_SERVICE_STATUS 字段（可能为 DISABLED、ENABLED、ENABLING、DISABLING）。

📊 4. 监控仲裁服务状态

• DBA_OB_TENANTS.ARBITRATION_SERVICE_STATUS：租户的仲裁服务启用状态。
• DBA_OB_ARBITRATION_SERVICE：集群添加的仲裁服务信息。
• GV$OB_LOG_STAT.DEGRADED_LIST：查看日志流降级状态。
• DBA_OB_SERVER_EVENT_HISTORY：查看日志流升降级事件历史。

♻️ 5. 升级与替换仲裁服务

注意事项：新替换的仲裁服务版本需与 OceanBase 集群的大版本保持一致，以确保兼容性。

-- 替换故障仲裁服务（在 sys 租户执行）
        ALTER SYSTEM REPLACE ARBITRATION SERVICE 'curr_arb_server_ip:curr_arb_server_port' WITH 'new_arb_server_ip:new_arb_server_port';

        -- 移除不再使用的仲裁服务
        ALTER SYSTEM REMOVE ARBITRATION SERVICE 'arb_server_ip:arb_server_port';

如果原仲裁服务在替换前为正常状态，系统会自动清理原仲裁服务器上残留的集群信息；如果原仲裁服务在替换前为故障状态，系统会有一个 Warning 信息，提示您仲裁服务替换成功后，原仲裁服务器需要手动清理。

在 OCP 平台创建的仲裁服务组中，当仲裁服务节点发生异常时，系统可根据优先配置实现秒级替换，实现仲裁服务本身的高可用。

仲裁方案的风险与权衡

仲裁方案与全功能副本部署相比，成本更低，但可用性也略低，在极端情况下可能存在数据丢失风险。

• 2F1A（两副本一仲裁）的潜在问题：1 个 F 副本故障触发降级后，只剩唯一 F 副本。如果此副本也发生故障且无法恢复，之后即使第一个 F 副本恢复了，也会导致数据丢失，原因在于仲裁成员不存储 Redo 日志，无法像 3F 部署那样自动恢复数据。因此仲裁方案适合对成本高度敏感，且能接受略低于 3F 集群可用性的场景。
• 自动降级依赖 timeout：仲裁服务的自动降级依赖于 arbitration_timeout 参数的设定，过短可能导致不必要的降级，过长可能影响 RTO。需要根据业务网络和容灾要求仔细权衡。
• 依赖租户 Locality：仲裁服务要求租户 Locality 严格为 2F 或 4F，这为租户的部署模式带来一定限制，尤其在进行跨集群主备切换等复杂操作时需格外谨慎。

OceanBase 数据库的存储引擎基于 LSM-Tree（Log-Structured Merge-Tree）架构。与 InnoDB 等传统数据库实时刷脏页不同，LSM-Tree 将内存中的随机写转化为对磁盘的顺序写，大幅提升写入性能。数据被分为两部分：MemTable（内存中的动态增量数据）和 SSTable（磁盘上的静态基线数据），SSTable 一旦生成即为只读，不再被修改。

MemTable：内存存储引擎

MemTable 是 OceanBase 的内存存储引擎，负责处理所有数据的写入操作。当一个 DML 操作到达时，数据首先写入 MemTable，写入成功后即向客户端返回成功，无需等待落盘。

• BTree + Hashtable 双引擎：MemTable 内部同时维护 BTree 和 Hashtable 两种索引结构，BTree 优化范围查询，Hashtable 优化点查性能，两个结构中存储的都是指向实际数据内存块的指针。
• Active + Frozen 双层设计：每个租户的内存中同时存在 Active MemTable（当前接收写入）和 Frozen MemTable（等待转储）。当 Active MemTable 内存占用达到阈值（即租户级配置 freeze_trigger_percentage * memstore_limit_percentage）时，系统执行 冻结（Freeze），将当前 Active 变为 Frozen 并激活新的 Active MemTable，确保写入永不阻塞。

-- 触发租户级别的转储（冻结 + 转储）
        ALTER SYSTEM MINOR FREEZE TENANT = tenant_name;

        -- 查看租户 MemStore 使用情况
        SELECT tenant_id, active_memstore_used, total_memstore_used, memstore_limit
        FROM oceanbase.GV$OB_MEMSTORE;

SSTable：磁盘存储结构

SSTable 是 OceanBase 在磁盘上的数据存储单元，一旦生成即为只读，不再被修改。多个转储生成的 SSTable 会在后续的合并过程中被归并，生成新的 SSTable。

• 宏块（Macroblock）：OceanBase 将数据文件按 2MB 固定大小切分为宏块，宏块是磁盘写入 IO 的基本单位。
• 微块（Microblock）：每个宏块内部进一步划分为多个变长微块（默认 16KB，可配置范围为 4KB 至 512KB），微块是磁盘读取 IO 的基本单位。微块支持 Flat（平铺）和 Encoding（编码）两种组织格式，基线数据（Major SSTable）可采用 Encoding 格式获得更高的压缩比。

-- 在建表时指定微块大小（单位：字节，可选 4096、8192、16384、32768、65536、131072 等）
        ALTER TABLE mytable SET block_size = 32768;

三层分层存储（Tiered & Leveled Compaction）

OceanBase 4.x 将磁盘上的 SSTable 划分为 L0、L1、L2 三层，采用 Tiered & Leveled 混合 Compaction 策略，在写入放大和读放大之间取得平衡。

L0 层内部分层：L0 层内部进一步划分为 level-0 到 level-n 多个子层，每层可容纳固定数量的 SSTable。当某层 SSTable 数量达到上限时，触发本层内合并，输出到下一子层；只有最底层 SSTable 数量达到上限时，才触发 L0 → L1 的跨层合并，从而有效控制读放大和写放大之间的平衡[reference:22]。

转储 vs 合并：核心区分

• 转储（Minor Compaction）：将 MemTable 转为 Mini SSTable，由 Mini Compaction 和 Minor Compaction 两个子过程组成。转储只处理增量数据，不涉及基线数据，对业务性能影响更小。
• 合并（Major Compaction）：将租户下所有分区的基线 SSTable 与增量 SSTable 归并，生成新的 Major SSTable。合并是租户级的全局操作，最终形成租户级快照，与转储的核心区别在于合并是在统一快照点与静态数据进行归并的行为。

查询路径与多级缓存优化

由于 OceanBase 采用基线 + 增量的设计，每次查询需要同时读取 MemTable（增量）和 SSTable（基线），并将结果归并后返回。为加速查询，OceanBase 实现了多级缓存体系：

• Block Cache：缓存从磁盘读取的微块（解压后），加速范围扫描和全表扫描。
• Row Cache：缓存具体的数据行，对于 Get/MultiGet 点查询可极大加速。
• Block Index Cache：缓存微块的索引，帮助在宏块中快速定位目标微块[reference:23]。
• Bloom Filter Cache：基于宏块按需构建，当宏块上空查次数超过阈值时自动创建，帮助快速过滤不存在的行，避免无效磁盘 I/O。
• Fuse Row Cache：缓存将多版本数据融合后的最终行，避免重复的版本合并计算，特别有利于热点行查询场景[reference:24]。

通过多级缓存体系，OLTP 类点查询可以接近内存数据库的性能，避免传统数据库解析整个数据块的开销。

4.x 架构优化亮点

• 自适应合并（Adaptive Compaction）：从 V4.2.0 版本开始支持，系统实时采集用户查询和写入信息，按需对分区调度合并任务，达到对用户无感知地解决慢查询问题。
• 表级 Buffer 表优化：允许为每张表设置独立的表级配置项，当表中墓碑记录存量达到阈值时，系统自动触发针对性合并，有效应对高频更新场景下的读放大问题。
• 列存引擎支持（V4.3.0+）：在 LSM-Tree 架构基础上扩展列存能力，实现行存与列存一体化存储，兼顾 TP 和 AP 查询性能。
• 每日合并机制：在多副本分布式部署基础上，引入每日合并概念，可定期或按需选择全局版本号进行合并。

Compaction（合并） 是 LSM-Tree 存储引擎的核心操作，本质上是数据的重新组织，其算法是一个多路归并排序——将多个 SSTable 按 Rowkey 排序后合并，最终输出为一个 SSTable。OceanBase 数据库通过设计精巧的 Compaction 策略，在写入性能、查询性能和空间利用率之间取得了良好的平衡。

合并类型总览

OceanBase 数据库支持以下五种合并类型：

转储（Minor Compaction）详解

转储由两个子过程构成：Mini Compaction（mini 合并） 和 Minor Compaction（minor 合并）。

📝 Mini Compaction（mini 合并）

当 MemTable 内存占用超过指定阈值（由租户级参数 freeze_trigger_percentage 控制）时，系统会触发转储（Mini Compaction），将 MemTable 中的数据落盘为 Mini SSTable，以释放内存空间。该过程持续进行，随着用户数据的不断写入，Mini SSTable 的数量也会不断增多。

🔄 Minor Compaction（minor 合并）

当 Mini SSTable 数量超过指定阈值（配置项 minor_compact_trigger）时，后台调度线程会自动触发 Minor Compaction。Minor Compaction 有两种合并策略：

• Mini Minor Compaction：当 L0 层 Mini SSTable 的个数超过配置项 minor_compact_trigger 的值时，将 L0 层的多个 Mini SSTable 合并为一个大的 Mini SSTable。
• Minor Compaction（minor 合并）：在满足第一种策略的同时，且 L0 层 Mini SSTable 的记录总数超过 L1 层 Minor SSTable 记录数的 25% 时，L0 层的多个 Mini SSTable 与 L1 层的 Minor SSTable 直接合并为一个新的 Minor SSTable。

合并（Major Compaction）详解

合并操作（Major Compaction） 是将动态增量数据和静态基线数据做归并，通常比较耗时。当转储产生的增量数据积累到一定程度时，系统通过 Major Freeze 实现大版本的合并。在最佳实践中，一般期望在一天只做一次合并操作，并且控制在业务低峰期进行，因此有时也会把合并称之为每日合并。

Major Compaction 的合并算法

按照合并数据量和合并方式，Major Compaction 可以分为以下四种算法：

• 全量合并：将静态数据全部读出并和动态数据合并为最终的静态数据。合并时间长，耗费 IO 和 CPU，是 OceanBase 数据库最初的合并算法，目前一般不会主动做全量合并。
• 增量合并：仅仅合并被修改过的宏块（Macroblock），没有改变的宏块进行复用。增量合并极大地减少了合并的工作量，是 OceanBase 数据库目前默认的合并算法。
• 渐进合并：每次全量合并一部分数据，若干轮次后整体数据被重写一遍。通过表级属性 progressive_merge_num 控制，特别适用于大表 Schema 变更场景。
• 并行合并：将数据划分到不同线程中并行做合并，通过多线程并行加速合并过程。

合并的触发方法

OceanBase 数据库支持多种合并触发方式：

1️⃣ 自动触发合并

当转储次数（即冻结次数，也即 minor_compaction 次数）超过配置项 major_compact_trigger 指定的阈值时，系统自动为租户调度一次租户级合并任务。

-- 查看 major_compact_trigger 配置（租户级）
        SHOW PARAMETERS LIKE 'major_compact_trigger';

        -- 设置转储 10 次后触发合并
        ALTER SYSTEM SET major_compact_trigger = 10;

        -- 注意：从 V4.0.0 版本开始，major_compact_trigger 的生效范围由集群级调整为租户级，默认值由 5 调整为 0（表示无论冻结多少次都不会自动触发合并）

该参数的控制范围为租户级，在自适应合并开启时，不建议使用 major_compact_trigger，因为租户级合并粒度更大，系统消耗的资源更多。

2️⃣ 定时触发合并

通过集群级配置项 major_freeze_duty_time 指定每天定时合并的时间（默认 02:00）。

-- 查看 daily major freeze 时间（集群级，需在 sys 租户下设置）
        SHOW PARAMETERS LIKE 'major_freeze_duty_time';

        -- 设置合并时间为每天 03:00
        ALTER SYSTEM SET major_freeze_duty_time = '03:00';

3️⃣ 手动触发合并

-- 触发租户级别合并（在 sys 租户下执行）
        ALTER SYSTEM MAJOR FREEZE TENANT = tenant_name;

        -- 全局触发合并（影响所有租户）
        ALTER SYSTEM MAJOR FREEZE;

4️⃣ 自适应合并（Adaptive Major Compaction）

从 OceanBase 数据库 V4.1.0 版本开始支持自适应合并功能。开启后，系统会实时采集并统计用户的查询、写入等信息，并按需为分区调度分区级合并任务，从而有效减少慢查询的发生。自适应合并由租户级隐藏配置项 _enable_adaptive_compaction 控制，默认值为 True。

-- 查询自适应合并是否开启（隐式配置项）
        SELECT * FROM oceanbase.GV$OB_PARAMETERS WHERE NAME LIKE '_enable_adaptive_compaction';

        -- 如需关闭自适应合并（建议联系技术支持），可将该配置项设置为 False

合并状态监控

合并的状态可以通过视图 DBA_OB_MAJOR_COMPACTION（或 CDB_OB_MAJOR_COMPACTION）中的 STATUS 列来查看：

-- 系统租户查询合并状态
        SELECT * FROM oceanbase.CDB_OB_MAJOR_COMPACTION;

        -- 普通租户查询合并状态
        SELECT * FROM oceanbase.DBA_OB_MAJOR_COMPACTION;

当 STATUS 为 IDLE，且 GLOBAL_BROADCAST_SCN 与 LAST_VERSION 的值相等时，说明合并结束。

合并的压缩算法

OceanBase 数据库在合并期间会对数据进行两层压缩：

• 第一层（编码压缩）：数据库内部基于语义的编码压缩。
• 第二层（通用压缩）：基于用户指定压缩算法的通用压缩。

可以通过参数 default_compress_func 配置压缩方式，默认值为 zstd_1.3.8。其他可指定的值还有 none、lz4_1.0、snappy_1.0、zstd_1.0、zlib_lite_1.0。更高的压缩率更节约磁盘空间，但也会带来一定的性能牺牲。

-- 创建表时指定压缩算法（MySQL 模式示例）
        CREATE TABLE mytable (id INT PRIMARY KEY, name VARCHAR(100)) COMPRESS='lz4_1.0';

        -- 修改表压缩算法
        ALTER TABLE mytable SET COMPRESS='zstd_1.3.8';

您也可以在建表时单独为表指定压缩算法。对于 OceanBase 这类 LSM-Tree 架构，数据压缩对写入性能几乎无影响。

合并的附加价值

合并除了数据归并的基本功能外，还带来以下价值：

• 数据压缩：通过两级压缩提升磁盘空间利用率。
• 数据校验：通过租户级一致快照，合并完成后多副本可以直接比对基线数据，确保业务数据在不同副本间一致；同时基于该快照基线数据做主表和索引表的数据校验。
• Schema 变更：对于加列、减列等 Schema 变更，OceanBase 可以在合并中一起完成数据变更操作，使得 DDL 操作对业务更加平滑。

合并调优与参数配置

OceanBase V4.x 版本以租户为粒度执行每日合并，可以根据不同租户的具体场景和要求，设置不同的合并参数。

核心合并参数

其中 compaction_dag_cnt_limit、compaction_schedule_tablet_batch_cnt、compaction_low_thread_score 和 compaction_high_thread_score 等配置项来源于合并慢的调优实践，在百万分区场景下对合并提速有显著效果。

合并慢的场景应对（OceanBase V4.x）

以下两种典型场景下可能需要进行合并调优：

• 百万分区场景：得益于架构优化，OceanBase V4.x 版本的一个 OBServer 或一个租户可以支持高达百万分区，更多的分区意味着更长的合并耗时。建议调整 compaction_dag_cnt_limit、compaction_schedule_tablet_batch_cnt 和 compaction_low_thread_score 等参数来优化合并速度。
• 列存场景（V4.3+）：列存表在合并时需要将行存的增量数据拆分到每个列的独立 SSTable 中，这会导致合并时间和资源占用相较于行存有较大增加。OceanBase 数据库对列存表的合并进行了大幅优化，支持水平拆分并行合并加速，还新增了垂直拆分加速机制，确保合并过程既高效又经济。

-- 百万分区场景示例配置
        ALTER SYSTEM SET compaction_dag_cnt_limit = 50000;
        ALTER SYSTEM SET compaction_schedule_tablet_batch_cnt = 100000;
        ALTER SYSTEM SET compaction_low_thread_score = 20;

传统架构往往面临“行存数据库 + 列存分析库”的外挂方案，虽能分别应对事务与分析，却不得不忍受数据同步延迟、存储冗余和运维复杂的高昂代价。OceanBase 从 V4.3.0 版本开始，基于 LSM-Tree 存储引擎原生扩展实现了列存支持，在一套架构下实现行存、列存与行列混存的一体化，用户无需双写或 ETL，即可在同一套系统中获得实时分析能力。[reference:0]

列存实现原理

OceanBase 列存引擎在磁盘上对数据进行了列式组织的重新表达，每列数据存储为一个独立的 SSTable，所有列的 SSTable 组合成为一个虚拟 SSTable 作为用户的列存基线数据。根据用户建表时指定的 WITH COLUMN GROUP 子句，基线数据可以有三种形态：

• 行存表：不指定 WITH COLUMN GROUP，增量数据保持行存，基线数据也存储为行存 SSTable，适合点查和高频写入场景。[reference:6]
• 列存表：指定 WITH COLUMN GROUP(each column)，基线数据存储为列存 SSTable，大幅提升 AP 扫描和压缩能力。[reference:7]
• 行列冗余表：指定 WITH COLUMN GROUP(all columns, each column)，基线数据同时存储行存和列存两份副本，优化器根据查询特征自动选择最优存储路径。[reference:8]

无论使用哪种存储模式，表的增量数据均保持行存格式，因此列存表的 DML、事务、上下游数据同步都不会受到影响。[reference:9]

-- 查看当前租户默认建表存储格式
        SHOW PARAMETERS LIKE 'default_table_store_format';

        -- 将租户默认建表格式设置为列存（V4.3.4+，新建表生效）
        ALTER SYSTEM SET default_table_store_format = 'column';

        -- 将租户默认建表格式设置为行列混存（V4.3.4+，新建表生效）
        ALTER SYSTEM SET default_table_store_format = 'compound';

-- 1. 列存表：适合纯 AP 分析场景
        CREATE TABLE tbl1_cg (col1 INT PRIMARY KEY, col2 VARCHAR(50))
            WITH COLUMN GROUP(each column);

        -- 2. 行列冗余表：适合 TP+AP 双负载混合场景
        CREATE TABLE tbl2_cg (col1 INT PRIMARY KEY, col2 VARCHAR(50))
            WITH COLUMN GROUP(all columns, each column);

        -- 3. 列存索引：主表行存 + 索引列存，适合行存表中少量分析查询的场景
        CREATE TABLE tbl3 (id INT, name VARCHAR(18), date DATE, PRIMARY KEY (id),
            INDEX idx1_tbl3_cg (date) WITH COLUMN GROUP(each column));

智能查询路由：优化器自动选择行存或列存

当表采用行列冗余表（行存 + 列存两份数据）时，OceanBase 优化器会根据查询特征和代价模型，自动判断应使用行存还是列存来执行查询：[reference:12]

• 点查或小范围扫描（如按主键精确读取）：优化器自动选择走行存，避免多余 I/O。
• 全表扫描或大范围聚合查询（如 SUM、GROUP BY）：优化器自动选择走列存，利用向量化执行引擎加速。
• 用户也可以通过 Hint /*+ STORING_MODE(ROW) */ 或 /*+ STORING_MODE(COLUMN) */ 强制指定路由。[reference:13]

当扫描范围大到行存需要的 IO 数大于等于访问列数 IO 数时，列存通常表现更优。简化评估建议：宽表（多于 64 列）扫描行数大于 1K，或非宽表扫描行数大于 8K 时，适合使用列存。[reference:14]

列存副本：物理资源隔离

OceanBase 从 V4.3.3 版本开始支持列存副本，这是一种专用于 AP 场景的新型副本类型。[reference:15]

• 核心特性：列存副本与只读副本类似，不参与选举和日志投票，拥有完整的 SSTable/clog/MemTable。用户表的基线数据使用列存方式存储。[reference:16]
• 部署方式：可以将列存副本部署在独立的 Zone 上，OLAP 业务通过独立的 ODP 入口访问列存副本，并以弱读方式执行决策分析类业务。[reference:17]
• 资源隔离效果：列存副本独立于 OLTP Leader 副本，使 AP 请求不再消耗 OLTP 业务的计算资源，实现物理层面的资源隔离。[reference:18]
• 版本要求：列存副本需要 OceanBase V4.3.3 版本及以上和 OCP V4.3.3 及以上。[reference:19]

-- 创建包含列存副本的租户示例（V4.3.3+）
        CREATE TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,C@zone3',
            primary_zone='zone1;zone2,zone3',
            RESOURCE_POOL_LIST=('pool1')
            SET ob_tcp_invited_nodes = '%';

Merge-On-Write（MOW）实时分析增强（V4.3.5+）

OceanBase 4.3.0 推出列存引擎后，AP 分析能力大幅提升，但当增量数据较多时，查询采用 Merge-On-Read 方式仍需处理增量数据，对实时分析有一定影响（“读放大”问题）。OceanBase 在 4.3.5 版本中提出了 Merge-On-Write 表，将更新拆分为 DELETE/INSERT 写入增量数据中，查询时分别对增量和基线数据进行处理，从而显著提高了更新频繁场景下 OceanBase 的实时分析能力。[reference:21]

常规生产环境测试结果显示，MOW 表相比普通表可实现 5 倍以上 的查询性能提升。[reference:22]

-- 创建 MOW 表（Merge-On-Write）
        CREATE TABLE t_mow (c1 INT, c2 INT)
            WITH COLUMN GROUP(each column)
            MERGE_ENGINE = delete_insert;

        -- 查看表是否为 MOW 表
        SHOW CREATE TABLE t_mow;

向量化执行引擎演进

OceanBase 从 4.0 版本开始向量化执行引擎默认开启，并在 4.3 版本中实现了向量化引擎 2.0，通过对数据格式、算子实现优化及存储向量化优化等方面的改进，大幅提升了向量化引擎的执行性能。向量化引擎 2.0 实现了新的按列的数据格式，将数据描述信息 null, len, ptr 信息分别按列的方式分开连续存放，避免了数据信息冗余存储，对 SIMD 使用也更友好。

性能基准与收益

OceanBase 列存引擎在 AP 场景下表现优异，TPC-H 100G 测试中，列存相比非向量化方式性能提升显著，已在网商银行、交通银行等金融核心系统中落地 HTAP 混合负载方案。相比传统的“OLTP + CDC + 数仓”方案，OceanBase 一体化 HTAP 架构有效降低了数据延迟、运维成本和存储冗余，支持实时交易与实时分析在单一系统中融合运行。

4.x 版本 HTAP 演进路线图

• V4.3.0：正式推出列存引擎，行列混存一体化，向量化执行引擎 2.0 发布。[reference:26]
• V4.3.3：正式支持列存副本，可在独立 Zone 上部署列存副本实现 HTAP 物理资源隔离。[reference:27]
• V4.3.5：Merge-On-Write 表发布，向量化执行引擎持续增强。[reference:28]
• V4.4.x+：复杂数据类型（Bitmap/Array/Map）、物化视图实时更新等能力持续演进。[reference:29]

Bloom Filter（布隆过滤器）是一种概率型数据结构，其核心功能是快速判断一个元素是否存在于一个集合中。在 LSM-Tree 架构中，数据被分散存储在多个 SSTable 内，如果某个键在 SSTable 中不存在，存储引擎仍需要扫描大量数据才能确定“不存在”，导致严重的读放大。Bloom Filter 通过在内存中维护一个极小的位图结构，使得系统可以快速过滤掉那些“肯定不存在”的查询请求，从而大幅降低磁盘 I/O，优化点查询和写入性能。

按需自动构建机制

在 OceanBase 数据库中，Bloom Filter 构建在 SSTable 的宏块（Macroblock，2MB 定长）粒度上，并采用按需自动构建策略，而非用户手动创建：

• 空查统计与阈值触发：系统会统计每个宏块上的空查次数（即查询该宏块后发现数据不存在的次数）。当一个宏块上的空查次数超过由配置项 bf_cache_miss_count_threshold 指定的阈值时（默认为 100），系统即判定该宏块为“读取效率低下”，会自动为该宏块构建对应的 Bloom Filter，并将其放入 Bloom Filter Cache 中[reference:15][reference:16]。
• 构建时的空间权衡：Bloom Filter 本质上是利用极小的空间代价换取大量的 I/O 节省。OceanBase 内部采用动态策略来平衡误判率与内存开销，确保在有效过滤空查请求的同时，不会过度占用宝贵的内存资源。
• 缓存管理：当内存压力增大需要淘汰缓存时，Bloom Filter Cache 会根据预设的缓存优先级（由配置项 bf_cache_priority 控制，默认值为 1）决定淘汰顺序[reference:17][reference:18]。

-- 查看 Bloom Filter 相关的系统配置项（集群级，在 sys 租户下执行）
        SHOW PARAMETERS LIKE 'bf_cache_miss_count_threshold';
        SHOW PARAMETERS LIKE 'bf_cache_priority';
        SHOW PARAMETERS LIKE 'bloom_filter_cache_size';

        -- 设置宏块空查触发阈值（低于该值时不构建 Bloom Filter，减少不必要的内存开销）
        ALTER SYSTEM SET bf_cache_miss_count_threshold = 100;

Bloom Filter 在多级缓存中的定位

OceanBase 的多级缓存体系以漏斗式层层过滤数据，Bloom Filter 处于整个查询路径的最前端，负责快速拦截绝大多数不存在的数据查询请求，避免底层 Cache 和磁盘被无效请求穿透。整个查询流程如下：

核心配置参数详解

Runtime Filter：SQL 执行层面的动态 Bloom Filter

除了存储层作为 SSTable 宏块数据的预过滤手段外，OceanBase 还在 SQL 执行层面引入了 Runtime Filter 技术。它是一种用于优化 Hash Join 性能的轻量级动态过滤器，通过构建 Bloom Filter 在线广播给 Probe 表，在存储引擎层提前过滤数据，大幅减少参与 Hash Join 的数据量和网络传输。

• 原理：执行 Hash Join 时，系统先扫描小表（Build 表），利用其 Join Key 实时构建一个 Bloom Filter，然后将其广播到大表（Probe 表）所在的节点。大表在扫描数据时，会利用该 Bloom Filter 预先过滤掉肯定不满足 Join 条件的数据[reference:24]。
• 适用场景：特别适用于 Build 表结果集较小的场景，如星形模型中与事实表 Join 的多张维度表[reference:25]。
• 分类：Runtime Filter 分为 Local（仅本节点）、Global（跨节点）和 Part Join Filter（分区剪裁）。标准 Runtime Filter 支持 Bloom Filter、In Filter 和 Range Filter 三种数据结构，而 Part Join Filter 当前仅支持 Bloom Filter[reference:26][reference:27]。

-- 启用 Runtime Filter 的 SQL Hint 示例（在 SELECT 语句中使用）
        SELECT /*+ PX_JOIN_FILTER(tt2) PARALLEL(4) */ *
        FROM tt1 JOIN tt2 ON tt1.v1 = tt2.v1;

        -- 通过 Session 变量开启 Runtime Filter（影响当前会话）
        SET SESSION runtime_filter_type = 'BLOOM_FILTER,RANGE,IN';

Bloom Filter 与列存/行列混存场景下的协同

在行列混存或列存模式下，Bloom Filter 的工作机制与行存场景有所不同，但仍扮演着关键的角色：

• 列存场景的 Bloom Filter：在 OceanBase V4.3.x 版本中，列存表的 Bloom Filter 构建在列存引擎对应的 SSTable 上，同样按需自动构建，用于加速针对列存数据的空值/空查过滤。
• 行列冗余场景的智能路由：当表采用行列冗余模式时，优化器会根据查询特征自动选择走行存还是列存。无论走哪种路径，Bloom Filter 都作为第一层防御，在各自的存储层上先行过滤无效请求。
• 列存副本场景：在 V4.3.3+ 的列存副本部署中，Bloom Filter 同样在列存副本上发挥作用，为 AP 查询提供独立于 OLTP 查询的过滤路径。

监控与性能调优

Bloom Filter 的性能可以通过相关指标进行监控和分析：

-- 查看 Bloom Filter Cache 的命中率（参考指标，具体视图名称根据版本略有差异）
        SELECT * FROM oceanbase.GV$OB_CACHE WHERE CACHE_NAME = 'bloom_filter_cache';

        -- 检查宏块粒度上的 Bloom Filter 构建情况（通过系统日志或特定性能视图）

最佳实践建议：

• 避免全局关闭 Bloom Filter：保持 bf_cache_miss_count_threshold 为默认值 100，除非在极其特殊的内存受限场景下，才考虑关闭。
• 合理设置缓存优先级：对于点查密集型业务，可适当调高 bf_cache_priority，确保 Bloom Filter Cache 在内存紧张时不会被过早淘汰。
• 结合业务特征进行分析：高频存在“空查”的业务场景（如防重复校验、用户不存在检查），Bloom Filter 的收益最为明显。
• 监控 Bloom Filter 命中率：若命中率长期偏低，可能意味着业务请求模式偏重于实际“存在”的数据，或宏块粒度上的 Bloom Filter 构建策略可进一步调优。
• Runtime Filter 使用建议：对于复杂 Join 查询，可适当使用 PX_JOIN_FILTER 等 Hint 开启 Runtime Filter 优化，显著提升 Join 查询性能。但该优化会引入一定的动态过滤计算开销，需结合实际情况权衡。

在 OceanBase 数据库中，**日志流（Log Stream，LS）** 是系统自动创建和管理的核心实体。它不仅有序地记录了数据的 Redo 日志，还包含了一组数据分片（Tablet）。每个日志流及其副本构成一个独立的 Paxos 组，日志流的 Leader 副本提供强一致性读写服务，Follower 副本通过 Paxos 协议同步日志，并支持弱一致性读。在 V4.x 架构中，**事务提交的基本单位从分区演进为日志流**。这一改变从根本上解决了 V3.x 版本中因海量分区而导致的元数据膨胀、心跳风暴、合并长耗时等问题，为支持百万级分区提供了架构基础。

基于日志流的分布式事务提交

在 OceanBase 4.x 中，日志流（LS）是分布式事务的基础单元和参与者。每个日志流内部通过自己的 WAL 机制来保证该日志流内所有数据修改的原子性。当事务涉及多个日志流时，系统会采用基于两阶段提交（2PC）的分布式协议来保证所有参与者的一致性。

传统 2PC 协议中存在“协调者单点”和“写日志多”的性能瓶颈。为此，OceanBase 对 2PC 进行了深度优化，其主要流程如下：

1. PREPARE 阶段

协调者向事务涉及的所有参与者（日志流 Leader）发起 Prepare 请求。参与者收到请求后，会决定是否可以提交。如果可以，则持久化 Prepare 日志，并返回 Prepare 成功；否则返回 Prepare 失败。在此阶段，参与者会持有受影响数据的行锁，直到事务最终 Commit 或 Rollback。

2. PRECOMMIT 阶段 (Commit Point)

这是 OceanBase 优化 2PC 协议的关键一步。当协调者收齐所有参与者的 Prepare 成功响应后，并不立即写入 Commit 日志，而是直接向客户端返回事务提交成功的信息。此时，事务进入一个中间过渡状态——**预提交（PRECOMMIT）**，事务的提交点确定，但全局清理工作尚未完成。

3. COMMIT 阶段

协调者向所有参与者发送事务 Commit 请求。参与者收到请求后，释放行锁，提交 Commit 日志，并在日志持久化后回复 Commit OK 消息，最后清理事务上下文。

4. CLEAR 阶段

OceanBase 引入的额外阶段，专门负责清理事务处理过程中产生的临时状态和数据，有助于系统更快地回收资源并减少对事务响应时间的影响。

Paxos 日志流与多副本高可用

OceanBase 的日志服务在 V4.0.0 版本被抽象为名为 **Palf（Paxos-backed Append-only Log File System）** 的组件，它像文件系统一样为数据库提供追加写的日志接口。

每个日志流与其副本构成一个独立的 Paxos 组。在这其中，一个副本担任 Leader（主副本），其余为 Follower（从副本）。Leader 负责处理写请求并将日志以 `LSN`（Log Sequence Number）的形式同步给 Follower。只有当日志在多数派（超过半数的 Paxos 成员）副本上持久化成功后，事务才能被视为提交成功，这保证了**RPO（恢复点目标）= 0**。当少数派副本（如一个 Follower）发生故障时，Paxos 协议能保证剩余的多数派副本（仍然过半）可以继续提供服务，并在 8 秒内完成 Leader 切换，确保**RTO（恢复时间目标）< 8s**。

-- 查看集群中所有日志流及其副本的角色分布
        SELECT LS_ID, SVR_IP, SVR_PORT, ROLE 
        FROM oceanbase.DBA_OB_LS_LOCATIONS;

        -- 查看日志流的详细信息，包括 Leader 信息
        SELECT LS_ID, STATUS, REPLICA_NUM, MEMBER_LIST, LEADER 
        FROM oceanbase.CDB_OB_LS_LOCATIONS 
        WHERE TENANT_ID = 1002;

多版本并发控制（MVCC，Multi-Version Concurrency Control）与全局时间戳服务（GTS，Global Timestamp Service）是 OceanBase 数据库实现高性能并发访问、读写不互斥以及分布式一致性的核心基石。每次数据更改会产生一个新版本，不同事务根据各自获取的全局时间戳读取对应的数据快照版本，从而使得读操作和写操作可以并行执行、互不阻塞。

MVCC 核心组成

OceanBase 的 MVCC 实现依赖三大核心组件，协同完成版本管理与一致性保障：

• 数据版本链（Version Chain）：每一行数据的每次更新都会生成一个新的版本，每个版本包含值（val）、版本号（ts）与事务ID（txn），通过回滚指针串联形成版本链。读请求无需加锁，只需根据自身版本号读取对应版本的数据，有效避免与写请求的冲突。
• 事务表（Transaction Table）：内存中维护的事务状态管理表，记录每个事务的ID、执行状态（RUNNING、PREPARE、COMMIT）以及对应的版本信息，用于判断数据版本的可见性与事务冲突处理。
• 全局时间戳服务（GTS）：负责为所有事务分配全局唯一的读版本号与提交版本号，确保分布式环境下所有节点的时间戳一致性，是 MVCC 实现跨节点数据可见性的核心基础。

MVCC 版本管理流程

每个事务在执行过程中会维护两个核心版本号：读版本号（用于读取数据时匹配可见版本）与提交版本号（用于数据更新时生成新版本）。核心流程如下：

• 事务启动：从 GTS 获取全局读版本号，作为本次事务读取数据的基准。
• 写操作：不会直接覆盖原数据，而是生成一个新版本，暂存于 MemStore，关联当前事务 ID 与临时版本号。
• 事务提交：进入两阶段提交流程，每个分区取本地最大读时间戳作为本地提交版本号，全局提交版本号取所有分区本地提交版本号的最大值。
• 提交完成：更新事务表状态，将全局提交版本号回填至新数据版本，并异步更新全局最大提交时间戳，供后续读请求判断可见性。

全局时间戳服务（GTS）的设计与实现

GTS（Global Timestamp Service）是 OceanBase 数据库中用于生成全局递增时间戳的核心服务，每个租户都会独立启动一个 GTS 服务。系统统一使用 GTS，事务提交时通过本租户的时间戳服务获取事务版本号，保证全局的事务顺序。在 V4.0.0 及之后版本中，原参数 ob_timestamp_service 已被删除，不再需要配置。

⏰ 时间戳正确性保证

GTS 服务通过精细的设计确保时间戳始终全局单调递增，即使发生 Leader 切换也不会有时间戳回退风险：

• 预分配区间机制：GTS Leader 会申请预分配的时间戳区间，并同步到仲裁日志。
• 新 Leader 恢复基准：新 Leader 上任前会回放原 Leader 写下的预分配区间日志，获取旧区间的最大值作为自己时间戳授权的基准值，确保新服务提供的时间戳不会退回到旧值。

⚡ GTS 高性能设计

GTS 每秒可处理数百万次时间戳获取请求，通过聚合和批量优化极大降低了系统开销：

• 语句快照优化：事务提交时更新 Global Committed Version，若查询只指向单个服务器，该语句可直接使用服务器的 Global Committed Version 作为 Read Version，从而减少对全局时间戳的请求压力。
• 批量获取优化：多个事务可以统一获取全局时间戳，通过提前发送请求来缩短事务提交的整体耗时。

🛡️ GTS 高可用架构

GTS 服务本身也是基于 Paxos 实现的高可用服务，具有多副本架构，确保服务的高可用性：

• 副本架构：每个租户的 GTS 服务默认有三个副本，分布在不同的 OBServer 节点上，实际对外提供时间戳服务的是 GTS 的 Leader 副本。
• Leader 运行位置：GTS 服务由租户级别 1 号日志流（Log Stream）的 Leader 提供，该 Leader 基于日志同步机制保证高可用性。时间来源于 Leader 上的持续化预分配区间。

-- 查看租户的 GTS 状态（V4.2.0+）
        -- 主租户显示当前已分配的 GTS 值，备租户显示当前可读位点（STS）值
        SELECT * FROM V$OB_TIMESTAMP_SERVICE;

        -- 系统租户下可查看所有租户的时钟
        SELECT TENANT_ID, TIMESTAMP, SOURCE_TYPE 
        FROM oceanbase.V$OB_TIMESTAMP_SERVICE;

快照读与数据可见性

在 OceanBase 中，查询语句默认执行的是快照读（Snapshot Read），即读取当前语句开始前所有已提交事务的数据：

• 语句级快照：每条 SELECT 语句在执行前都会获取最新的全局快照，仅能读到语句开始前已经提交的数据，避免脏读。
• 写操作的当前读：UPDATE、DELETE、SELECT FOR UPDATE 等操作需要获取当前读，会等待目标行上的未提交事务完成后重新执行语句，确保在最新数据基础上修改。

事务隔离级别支持

OceanBase 数据库在不同兼容模式下支持不同的隔离级别，但底层实际只实现了两种隔离级别：

OceanBase 数据库默认的隔离级别为读已提交。在底层只实现了读已提交和可串行化两种隔离级别，当用户在 MySQL 模式中指定可重复读时，实际使用的是可串行化，不会出现幻读的异常情况。读已提交不会出现脏读，但可能出现不可重复读和幻读。

-- 通过 Hint 指定弱一致性读
        SELECT /*+READ_CONSISTENCY(WEAK) */ * FROM orders;

        -- 通过 Session 变量设置弱一致性读
        SET SESSION ob_read_consistency = 'WEAK';

多版本数据回收机制

OceanBase 通过转储（Minor Compaction）和合并（Major Compaction）机制来回收多版本数据：

• undo_retention 配置项：用于控制系统应保留的多版本数据范围，在转储时控制多版本数据的回收，默认值为 1800 秒。当 undo_retention 值为 0 时，表示未开启多版本转储，转储文件仅保留当前最新版本的行数据。
• 转储（Minor Compaction）：将内存中 MemTable 的数据落盘为 Mini SSTable。转储时会根据 undo_retention 保留指定时间范围内的多版本数据。
• 合并（Major Compaction）：合并过程中会回收旧版本数据，Major SSTable 中不会存放多版本数据，这是释放存储空间的关键操作。

-- 查看多版本数据保留时间（秒）
        SHOW PARAMETERS LIKE 'undo_retention';

        -- 调整多版本保留时间（默认为 1800 秒）
        ALTER SYSTEM SET undo_retention = 3600;

OceanBase 作为一个原生分布式数据库，需要在分布式环境下完整实现事务的 ACID 特性。与传统单机数据库不同，分布式架构下数据分布在多个节点上，实现 ACID 面临更大的技术挑战。OceanBase 通过一系列创新机制，在保证强一致性的同时实现了高性能和高可用。

原子性（Atomicity）：优化版两阶段提交

OceanBase 通过改进的两阶段提交（2PC）协议保证分布式事务的原子性，确保跨多个参与者的操作要么全部提交，要么全部回滚。与传统 2PC 相比，OceanBase 实现了多项关键优化，将分布式事务的提交延迟减少到几乎只有一次交互的程度。

核心优化点

• 协调者无状态设计：传统 2PC 中协调者在 PREPARE 和 COMMIT 阶段都会写日志，成为性能和可靠性瓶颈。OceanBase 的协调者不负责写任何日志，大幅减少了磁盘 IO 操作。
• 引入 CLEAR 阶段：OceanBase 在传统 2PC 基础上引入了一个额外的 CLEAR 阶段，专门负责清理事务处理过程中产生的临时状态和数据，有助于系统更快地回收资源并减少对事务响应时间的影响。
• 提前返回客户端：在 PREPARE 阶段收齐所有参与者的成功响应后，协调者直接向客户端返回事务提交成功，无需等待第二阶段完成，性能大幅提升。

性能提升效果

一个分布式事务，OceanBase 的两阶段提交协议需要 2 次 RPC（Prepare 和 Commit 请求）和 2 次 IO 耗时，而传统两阶段提交协议需要 2 次 RPC 和 4 次 IO 耗时，性能显著提升。事务持有行锁的时机并没有延长，对事务的响应时间没有负面影响。

-- 查看事务超时相关参数
        -- 单条 SQL 超时时间（默认 10 秒）
        SHOW PARAMETERS LIKE 'ob_query_timeout';

        -- 整个事务超时时间（默认 100 秒）
        SHOW PARAMETERS LIKE 'ob_trx_timeout';

        -- 事务空闲超时时间（默认 24 小时）
        SHOW VARIABLES LIKE 'ob_trx_idle_timeout';

        -- 修改事务超时时间为 200 秒
        ALTER SYSTEM SET ob_trx_timeout = '200s';

一致性（Consistency）：全局时间戳与约束保障

OceanBase 通过全局时间戳服务（GTS）和完整性约束来保证数据的一致性。其中一致性是 ACID 的最终目的，原子性、隔离性和持久性是保证一致性的手段。

全局时间戳服务（GTS）

GTS（Global Timestamp Service）为每个租户独立启动，为所有事务分配全局唯一的读版本号和提交版本号，保证分布式环境下的外部一致性。

• 全局单调递增：所有事务版本号全局有序，保证跨节点的事务顺序。
• 高可用设计：GTS 本身基于 Paxos 实现，具有多副本架构。新 Leader 上任前会回放旧 Leader 的预分配区间日志，确保时间戳不回退。
• 高性能优化：通过语句快照优化和批量获取优化，GTS 每秒可处理数百万次时间戳请求。

隔离性（Isolation）：MVCC + 锁机制

OceanBase 基于多版本并发控制（MVCC）和行锁机制实现并发控制，实现读写不互斥和写写互斥，大幅提升系统并发能力。

MVCC 多版本并发控制

OceanBase 的 MVCC 依赖三大核心组件协同完成版本管理与一致性保障：

• 数据版本链：每行数据每次更新都生成新版本，包含值（val）、版本号（ts）与事务 ID（txn），通过回滚指针串联形成版本链。
• 事务表：内存中维护的事务状态管理表，记录每个事务的 ID、执行状态（RUNNING、PREPARE、COMMIT）以及对应的版本信息，用于判断数据版本的可见性与事务冲突处理。
• 全局时间戳服务（GTS）：负责为所有事务分配全局唯一的读版本号与提交版本号，是 MVCC 实现跨节点数据可见性的核心基础。

隔离级别与版本号获取策略

OceanBase 底层实际只实现了两种隔离级别，不同隔离级别下读取版本号的获取时机不同：

锁机制：行锁与表锁

OceanBase 对所有修改的行加互斥锁，实现写-写互斥。读操作读取特定快照版本的数据，实现读写互不阻塞。

• 行锁等待管理（Lock Wait Mgr）：系统在内存中维护锁的等待关系，当一个锁被释放时，会唤醒其他正在等待该锁的事务。
• 锁等待类型：Lock Wait Mgr 维护三种锁等待关系——行锁等待、表锁等待和事务等待。
• 表锁支持：OceanBase 支持锁定单个表、多个表或表的分区和子分区。

-- 查看当前锁等待信息
        SELECT * FROM oceanbase.GV$OB_LOCKS;

        -- 查看事务锁等待关系
        SELECT * FROM oceanbase.GV$OB_TRX_LOCK_WAIT;

        -- 通过 DBA_OB_DEADLOCK_EVENT_HISTORY 查看死锁事件
        SELECT * FROM oceanbase.DBA_OB_DEADLOCK_EVENT_HISTORY;

分布式死锁检测

OceanBase 支持分布式死锁自动检测功能，能够自动发现并解决死锁问题。

• 主动检测与消除：相比基于事务超时处理死锁的方案，分布式死锁自动检测能够及时发现并解决死锁，减少业务死锁对系统性能的影响。
• 可观测性：用户可以查询 DBA_OB_DEADLOCK_EVENT_HISTORY 视图，获得过去 7 天发生过的所有死锁事件、参与这些事件的事务，以及哪个事务被最终 Kill 掉，从而优化业务逻辑，避免死锁发生。
• 高级算法：OceanBase 推出了 LCL+ 算法，是一套"无需全局视图、消息轻量、单受害者解锁"的分布式死锁检测算法，针对混合死锁做了加速优化，相关成果已入选 ACM TOCS。

持久性（Durability）：Redo Log + Paxos 多数派

OceanBase 通过 Redo Log 预写日志（WAL）和基于 Paxos 的多副本同步机制保证事务持久性。

WAL 机制

事务提交前，Redo 日志必须先持久化。传统数据库中，一个事务的 Redo 日志在提交时一次性生成并落盘。OceanBase 从 V3.x 开始支持实时日志写入，当一个事务的数据达到 2MB 时，会实时生成并提交 Redo 日志到 Clog 模块，以提升大事务的性能。

Paxos 多数派同步

每个 Redo 日志需要通过 Multi-Paxos 协议同步到多数派副本（如三副本中的两个）后，才被视为成功写入：

• RPO=0：日志在多数派副本持久化成功才返回客户端成功，保证单副本故障不会导致数据丢失。
• RTO<8s：当少数派副本发生故障时，Paxos 协议能保证剩余多数派副本继续提供服务，并在 8 秒内自动完成 Leader 切换。
• PALF 日志系统：OceanBase V4.0.0 将日志服务抽象为 "Paxos Backed Append Only Log File System"（PALF），作为数据库的基础组件，统一满足事务系统的 WAL 需求和分布式系统的高可用需求。

读写分离与弱一致性读

OceanBase 提供了两种一致性级别：

• STRONG（强一致性）：读取最新数据，请求路由给 Leader 副本。写操作始终为强一致性。
• WEAK（弱一致性）：不要求读取最新数据，请求优先路由给 Follower 副本，配合 LDC 可实现就近读取，显著降低读延迟。

弱一致性读提供 有界旧保证（Bounded Staleness），通过租户级配置项 max_stale_time_for_weak_consistency 定义最大弱读落后时间（默认 5 秒），保证读取的数据不会落后于最新数据超过特定时间。同时还提供单调读一致性，通过设置 enable_monotonic_weak_read（默认 True）保证弱一致性读的版本单调性。

多版本数据回收机制

OceanBase 通过转储（Minor Compaction）和合并（Major Compaction）机制来回收多版本数据：

• undo_retention 配置项：用于控制系统应保留的多版本数据范围，在转储时控制多版本数据的回收，默认值为 1800 秒。当 undo_retention 值为 0 时，表示未开启多版本转储，转储文件仅保留当前最新版本的行数据。
• 转储（Minor Compaction）：将内存中 MemTable 的数据落盘为 Mini SSTable。转储时会根据 undo_retention 保留指定时间范围内的多版本数据。
• 合并（Major Compaction）：合并过程中会回收旧版本数据，Major SSTable 中不会存放多版本数据，这是释放存储空间的关键操作。

-- 查看多版本数据保留时间（秒）
        SHOW PARAMETERS LIKE 'undo_retention';

        -- 调整多版本保留时间（默认为 1800 秒）
        ALTER SYSTEM SET undo_retention = 3600;

在分布式数据库环境中，事务可能涉及多个节点，锁等待关系跨节点分布，使得死锁检测比单机环境更加复杂。OceanBase 通过基于锁链长度的分布式死锁检测算法（LCL/LCL+）以及多层级超时控制机制，实现了对死锁和悬挂事务的自动发现与处理，在保证 ACID 属性的同时，最大限度地降低了对业务性能的影响。

分布式死锁检测算法：LCL 到 LCL+ 的演进

LCL 算法：解决多出度场景的死锁检测

在 OceanBase 3.x 时代，团队提出了基于锁链长度（Lock Chain Length，LCL）的分布式死锁检测与消除算法，旨在克服 M&M 算法和 CMH 算法的固有局限：

• M&M 算法：简单且完全分布式，但其核心假设是“每个事务一次只等待一个资源”，无法处理现代分布式数据库中的多出度（multiple out-degree）场景（如并行查询中一个事务同时等待多个资源）。
• CMH 算法（Chandy-Misra-Haas）：采用“边追逐”机制通过探测消息发现环路，但存在多受害者缺陷——同一个死锁环路中多个并发探测可能导致多个事务被错误终止，与 OceanBase 所要求的“单受害者”原子性解决范式冲突。

LCL 算法通过维护每个等待节点的锁链长度（Lock Chain Length Value），该值会沿依赖链单向传播：有环时环内 LCLV 不断增大，无环路径则收敛到上界。算法通过三个核心阶段实现纯分布式的死锁检测：

• Stage 1：Proliferation（繁殖）——沿依赖边单向传播并递增 LCLV，使无环路径收敛、环内数值持续上升，从数值上区分环与非环。
• Stage 2：Spread（扩散）——同步环内的最大 LCLV，并基于预设“终止优先级”（如时间戳/事务优先级）选出唯一受害者。
• Stage 3：Detection（确认）——满足“三等式”条件时，确认该节点即为受害者，随后仅终止一个事务即可打破死锁，严格实现单受害者解锁范式。

LCL+ 算法：加速混合死锁检测

随着分布式架构的演进，OceanBase 4.x 面临新的挑战：混合死锁（Hybrid Deadlock）——死锁环路中同时包含同一服务器内的本地等待关系和跨服务器的分布式等待关系。LCL 算法对本地和分布式等待一视同仁，导致快速的本地依赖关系被慢速的分布式协议拖累，形成性能瓶颈。

为解决这一问题，OceanBase 团队在 LCL 基础上推出了 LCL+ 算法——一套“无需全局视图、消息轻量、单受害者解锁”的分布式算法，其核心创新在于引入 Stage-0 预繁殖（Pre-proliferation）阶段，在算法早期就即时识别本地/混合死锁并加速处理。LCL+ 算法已在 OceanBase 4.x 中落地部署，并在 ACM Transactions on Computer Systems（ACM TOCS）顶刊发表论文。

多层级超时控制体系

OceanBase 提供了完整的多层级超时控制机制，作为死锁检测的兜底策略，同时也用于处理非死锁场景下的悬挂事务和长事务：

1. 空闲超时（Idle Timeout）——ob_trx_idle_timeout

控制事务内两条 SQL 之间的最大空闲间隔。当一个事务中的两条 SQL 间隔超过该阈值时，OceanBase 会强制终止会话并回滚事务[reference:13]。

• 默认值：86400000000 微秒，即 24 小时[reference:14]。
• 作用范围：租户级系统变量。
• 应用场景：解决长事务、悬挂事务问题，避免事务因应用程序异常（如网络中断后未正确提交）而长时间占用锁资源。

2. 语句超时（Query Timeout）——ob_query_timeout

控制单条 SQL 语句在 OBServer 端的最大执行时间。如果一条 SQL 执行时间超过该阈值，OBServer 会返回错误码 4012[reference:15]。

• 默认值：10000000 微秒，即 10 秒[reference:16]。
• 作用范围：会话级变量。
• 应用场景：防止慢查询长期占用资源，影响系统整体性能。

3. 事务超时（Transaction Timeout）——ob_trx_timeout

控制整个事务从开始到结束的最大持续时间（包含空闲时间和活跃时间）。如果事务持续时间超过该阈值仍未结束，后续 SQL 将收到 Transaction is timeout 错误，事务会被回滚[reference:17]。

• V3.x 默认值：100000000 微秒，即 100 秒
• V4.x 默认值：86400000000 微秒，即 1 天[reference:18]
• 作用范围：会话级变量。
• 超时后行为：如果超时发生时事务尚未提交，OBServer 会回滚该事务；如果发生在提交阶段，由于事务状态未定，系统不会主动回滚[reference:19]。

-- 查看当前超时参数设置
        SHOW VARIABLES LIKE 'ob_trx_idle_timeout';
        SHOW VARIABLES LIKE 'ob_query_timeout';
        SHOW VARIABLES LIKE 'ob_trx_timeout';

        -- 修改超时参数示例（会话级别）
        SET ob_trx_timeout = 200000000;   -- 设置为 200 秒
        SET ob_query_timeout = 30000000;  -- 设置为 30 秒

4. 锁等待超时——ob_trx_lock_timeout

控制事务在等待行锁释放时的最长等待时间。当事务因锁冲突需要等待时，该参数决定了等待的上限。

• 默认值：-1，表示不生效，关闭超时机制[reference:20]。
• 取值范围：[0, +∞)，单位为微秒。0 表示 NO WAIT[reference:21]。
• 生效逻辑：当 ob_trx_lock_timeout 为 -1 时，行锁冲突等待时间使用 ob_query_timeout 的值；当为非 -1 值时，等待时间为 ob_trx_lock_timeout 与 ob_query_timeout 中的较小值。

-- 设置 NO WAIT 模式（等待锁时立即返回错误）
        SET ob_trx_lock_timeout = 0;

        -- 设置锁等待超时为 3 秒
        SET ob_trx_lock_timeout = 3000000;

5. 悬挂事务处理——_xa_timeout

OceanBase 提供了隐藏配置项 _xa_timeout，用于控制悬挂事务（XA 事务）的自动清理机制。当事务停留时间超过该阈值（默认 300 秒）时，事务会被自动回滚，避免悬挂事务持续阻塞其他操作[reference:22]。

-- 查看悬挂事务超时设置（需 sys 租户）
        SHOW PARAMETERS LIKE '_xa_timeout';

        -- 调整悬挂事务超时时间
        ALTER SYSTEM SET _xa_timeout = '30s';

死锁可观测性：监控视图与历史记录

OceanBase 提供了完善的锁监控与死锁事件记录视图，帮助 DBA 快速定位和排查死锁问题。

🔍 GV$OB_LOCKS：实时锁状态监控

GV$OB_LOCKS 视图（V4.2.0+ 引入）展示当前用户各表持锁或请求锁的情况，是实时排查锁阻塞问题的核心视图[reference:23]。

• 锁类型（TYPE）：TM（表锁）、TX（事务锁）、TR（行锁）[reference:24]。
• CTIME：持有或等待锁的时间（微秒）。
• BLOCK：0 表示当前事务持有锁，1 表示当前事务被阻塞等待锁。
• 锁模式（LMODE/REQUEST）：RS（行共享）、RX（行独占）、S（共享）、X（独占）等[reference:25]。

-- 查看当前锁阻塞情况，找出被阻塞的事务及等待时间
        SELECT svr_ip, svr_port, trans_id, type, ctime, block
        FROM oceanbase.GV$OB_LOCKS
        WHERE block = 1;

        -- 查看特定租户的事务锁等待详情
        SELECT svr_ip, trans_id, type, lmode, request, ctime
        FROM oceanbase.GV$OB_LOCKS
        WHERE tenant_id = 1002 AND block = 1;

📜 DBA_OB_DEADLOCK_EVENT_HISTORY：死锁事件历史记录

DBA_OB_DEADLOCK_EVENT_HISTORY 视图（V4.0.0+ 引入）展示当前租户下死锁事件的历史记录，可查询过去 7 天内发生过的所有死锁事件、参与这些事件的事务，以及该死锁事件中被回滚的事务[reference:26][reference:27]。

-- 查看当前租户的死锁历史记录
        SELECT event_id, report_time, cycle_size, 
            role, priority_level, priority,
            object, visitor
        FROM oceanbase.DBA_OB_DEADLOCK_EVENT_HISTORY
        ORDER BY report_time DESC
        LIMIT 10;

        -- 从系统租户查看所有租户的死锁事件
        SELECT * FROM oceanbase.CDB_OB_DEADLOCK_EVENT_HISTORY
        ORDER BY report_time DESC;

长事务与悬挂事务排查指南

当系统出现锁阻塞或性能问题时，可通过以下步骤排查长事务和悬挂事务：

1. 查询当前运行中的长事务

-- 查看当前租户中运行超过阈值的事务
        SELECT trans_id, tenant_id, svr_ip, svr_port, 
            trans_start_time, trans_timeout, state
        FROM oceanbase.GV$OB_TRANSACTION
        WHERE trans_start_time < DATE_SUB(NOW(), INTERVAL 30 MINUTE);

2. 定位阻塞源头

-- 找出当前被阻塞的事务及持有锁的事务
        SELECT blocked.trans_id AS blocked_trans,
            holder.trans_id AS holder_trans,
            blocked.ctime AS wait_time_us
        FROM oceanbase.GV$OB_LOCKS blocked
        JOIN oceanbase.GV$OB_LOCKS holder 
        ON blocked.object = holder.object
        WHERE blocked.block = 1 
        AND holder.block = 0;

3. 强制终止阻塞事务

-- 找出阻塞事务的 session_id 并 kill
        SELECT * FROM oceanbase.GV$OB_PROCESSLIST WHERE trans_id = [blocked_trans_id];
        KILL [session_id];

OceanBase 数据库提供了在线物理备份功能，由日志归档和数据备份两大核心子功能组成。日志归档持续维护租户产生的日志，提供了准实时的备份能力；数据备份则维护快照点的备份。两者结合，可以实现将租户恢复到备份位点之后的任意时间点（PITR）。物理备份以租户为粒度进行，支持系统租户或用户租户发起备份任务，但不支持对 sys 租户和 Meta 租户进行备份[reference:14]。

日志归档

OceanBase 数据库提供了租户级别的日志归档能力，是物理备份的核心组成部分之一。

核心机制

• 日志流 Leader 负责归档：日志归档的工作由租户内每个日志流（Log Stream）的 Leader 副本负责，按照日志流进行物理备份，是 Log Entry 级别的备份。
• 准实时备份：日志备份的周期默认为 2 分钟，提供了准实时的备份能力，数据丢失风险窗口极小。
• Piece 分片管理：系统默认按 24 小时拆分目录的功能，方便用户对于备份数据的管理。每个 Piece 包含该时间窗口内的所有日志，这种分片设计使得 PITR 可以快速定位到目标时间所在的 Piece，避免扫描全部历史日志[reference:15]。
• V4.x 架构优化：与之前版本（V2.2.x 和 V3.x）的 OceanBase 数据库相比，V4.x 的日志归档不再基于分区级别的日志管理，大幅降低了归档时产生的 IO 次数，有效降低了对备份介质的性能要求[reference:16]。

-- 配置日志归档路径（sys 租户为指定租户配置）
        ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=file:///obbackup/tenant1/clog
            BINDING=Optional PIECE_SWITCH_INTERVAL=1d' TENANT=tenant1;

        -- 配置日志归档路径（用户租户执行）
        ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=file:///obbackup/clog 
            BINDING=Optional PIECE_SWITCH_INTERVAL=1d';

        -- 启动日志归档
        ALTER SYSTEM ARCHIVELOG;

        -- 停止日志归档
        ALTER SYSTEM NOARCHIVELOG;

数据备份

OceanBase 数据库提供了租户级别的数据备份能力，包括全量备份和增量备份两种类型。数据备份的流程由 RootService 节点调度，并按照日志流进行备份[reference:17]。

全量备份

全量备份是指备份所有需要作为基线数据存储的宏块（Macroblock）。备份数据包括分区的元信息（内存序列化后的值）和宏块数据（物理备份的核心内容）。

增量备份

增量备份是从上一次全量备份或增量备份开始，备份所有修改后的宏块，即仅针对已备份数据的增量部分进行备份。

• 备份逻辑：如果租户最近一次是全量备份，系统会备份最近一次全量备份之后修改的所有宏块；如果最近一次是增量备份，则备份最近一次增量备份之后修改的所有宏块。
• 转换规则：如果在不存在全量数据备份的情况下直接发起增量备份，系统默认会将增量备份转换为全量备份。
• 升级场景处理：对于低版本集群升级到高版本集群的场景，即使当前租户在低版本中已经执行了全量备份，升级后直接发起增量备份，系统默认也会将增量备份转换为全量备份。

核心机制

• 全局唯一逻辑标识：OceanBase 数据库的基线宏块具有全局唯一的逻辑标识，这个逻辑标识提供了增量备份重用宏块的能力。增量备份的恢复和全量备份的恢复在流程上基本一致，性能上也没有差别，只是会根据逻辑标识在不同的 backup_set 之间读取宏块。
• 优先选择 Follower 节点：在 V4.x 版本中，OceanBase 数据库在选择备份服务器时会优先考虑日志流的 Follower 节点，这样可以减轻日志流 Leader 节点的压力，提高备份效率。具体表现在，系统会首先选择所有符合条件的 Follower 节点进行备份，只有在必要时才会选择 Leader 节点，确保备份过程更加高效和稳定。
• V4.x 架构优化：与之前版本（V2.2.x 和 V3.x）相比，V4.x 的数据备份去掉了数据快照点保留的依赖，在数据备份期间发起 Major Freeze 不会再造成节点空间的膨胀。

-- 发起全量备份（sys 租户为指定租户发起）
        ALTER SYSTEM BACKUP TENANT = tenant1;

        -- 发起全量备份（sys 租户对所有租户发起）
        ALTER SYSTEM BACKUP DATABASE;

        -- 发起增量备份（sys 租户为指定租户发起）
        ALTER SYSTEM BACKUP INCREMENTAL TENANT = tenant1;

        -- 发起增量备份（sys 租户对所有租户发起）
        ALTER SYSTEM BACKUP INCREMENTAL DATABASE;

备份目的端支持

OceanBase 数据库支持两种类型的备份目的端存储介质：

• Network File System (NFS)：网络文件系统，适用于本地或同城备份场景。
• Object Storage Service (OSS)：对象存储服务（如阿里云 OSS、AWS S3 等），适用于云上备份场景，支持跨地域容灾。

备份目录结构

OceanBase 数据库在备份目的端会创建规范的目录结构来组织备份数据：

backup/                          # 备份根目录
        └── ob1                          # 集群名称
            └── 1                        # 集群 ID
                └── incarnation_1        # 分身 ID
                    ├── 1001             # 租户 ID
                    │   ├── clog/        # 日志备份根目录
                    │   │   ├── 1/       # 日志备份轮次 ID
                    │   │   │   ├── data/      # 日志数据文件
                    │   │   │   └── index/     # 日志索引文件
                    │   │   └── tenant_clog_backup_info  # 日志备份元信息
                    │   └── data/        # 数据备份根目录
                    │       ├── backup_set_1/       # 第 1 次全量备份
                    │       │   ├── backup_1/       # 第 1 次增量备份
                    │       │   ├── backup_2/       # 第 2 次增量备份
                    │       │   ├── backup_set_info/
                    │       │   └── data/           # 宏块数据
                    │       └── tenant_data_backup_info/
                    ├── clog_info/                 # Server 启动日志备份信息
                    ├── cluster_clog_backup_info/  # 集群级日志备份元信息
                    ├── cluster_data_backup_info/  # 集群级数据备份元信息
                    └── tenant_info/              # 租户信息
                        └── tenant_name_info/     # 租户名称与 ID 映射关系

更多目录结构说明，请参见备份架构章节中的完整目录树。

配置参数详解

V4.x 版本对物理备份恢复功能进行了架构优化调整，相关配置项也发生了重要变化：

1. 日志归档并发度——log_archive_concurrency

用于设置日志归档的并发度，该配置项从 V4.1.0 版本开始生效范围调整为租户级。

• 默认值：0，表示使用 OceanBase 数据库自适应的日志归档并行度。从 V4.2.0 版本开始默认值从 1 调整为 0[reference:18]。
• 取值范围：[0, 100]，从 V4.2.0 版本开始取值范围由 [1,100] 调整为 [0,100][reference:19]。
• 自适应规则：归档工作线程数根据租户 max_cpu 自适应值计算：若 max_cpu ≤ 8，则归档线程数 = max_cpu；若 8 < max_cpu < 32，则归档线程数 = max_cpu / 2（最小值为 8）；若 max_cpu ≥ 32，则归档线程数 = max_cpu / 4（最小值为 16）。
• 生效方式：修改后无需重启 OBServer 节点，立即生效[reference:20]。

-- 在 sys 租户中修改指定租户的日志归档并发度
        ALTER SYSTEM SET log_archive_concurrency = 10 TENANT = mysql_tenant;

        -- 在 sys 租户中修改所有租户的日志归档并发度
        ALTER SYSTEM SET log_archive_concurrency = 10 TENANT = all_user;

        -- 在用户租户中修改本租户的日志归档并发度
        ALTER SYSTEM SET log_archive_concurrency = 10;

2. 备份线程并发度——ha_low_thread_score

V4.x 版本中，根据任务的优先级和重要程度，原有的 backup_concurrency 配置项（用于设置备份时写文件系统的并发数量）从 V4.0.0 版本开始删除，被细分为三个高可用相关的配置项[reference:21]。

• ha_high_thread_score：用于控制复制、Rebuild 和恢复等高可用高优先级线程的工作线程数[reference:22]。
• ha_mid_thread_score：用于控制迁移任务等高可用中优先级线程的工作线程数。
• ha_low_thread_score：用于控制备份、备份清理等高可用低优先级线程的工作线程数。默认值为 0，取值范围为 [0, 100]。在开始备份前，可以适当提高该值，建议每次将数值翻倍。

-- 设置集群中所有租户的备份并发度
        ALTER SYSTEM SET ha_low_thread_score = 10 TENANT = all_user;

        -- 设置集群中指定租户的备份并发度
        ALTER SYSTEM SET ha_low_thread_score = 10 TENANT = mysql_tenant;

3. 网络带宽限制——sys_bkgd_net_percentage

集群级配置项，用于设置后台系统任务（包含备份恢复任务）可占用的网络带宽百分比，默认值为机器网卡速率的 60%。带宽满时，在不影响业务请求的前提下，可以适当调大该值。

-- 查看当前网络带宽限制配置
        SHOW PARAMETERS LIKE 'sys_bkgd_net_percentage';

        -- 调整后台任务网络带宽占比为 70%
        ALTER SYSTEM SET sys_bkgd_net_percentage = 70;

4. 备份相关的配置项在 V4.x 版本中的演进

自动清理策略

OceanBase 数据库提供了当前配置路径下自动清理的功能，由 RootService 定期检查用户配置的备份清理策略，从而删除不需要的数据备份。在删除数据备份的同时，系统会自动根据保留的数据备份中最小的回放位点来删除不需要的日志备份。

-- 设置备份保留策略（保留最近 7 天的备份）
        ALTER SYSTEM SET BACKUP_RETENTION_POLICY = 'RETENTION 7 DAYS';

        -- 通过回收窗口设置保留策略
        ALTER SYSTEM SET BACKUP_RETENTION_POLICY = 'RECOVERY_WINDOW 7 DAYS';

        -- 查看备份清理策略
        SHOW PARAMETERS LIKE 'backup_retention%';

        -- 手动触发清理
        ALTER SYSTEM DELETE BACKUP;

OceanBase 数据库的物理备份操作需遵循"先配置、再开启、后执行"的科学流程：首先配置日志归档与数据备份的目的端，然后开启归档模式，最后才能执行数据备份。本节将通过实例，详细讲解从配置备份路径、启动归档、执行备份，到最终恢复租户数据的完整操作流程。V4.x 版本已将物理备份的配置和调度下沉到租户级别，相关 SQL 和视图也相应进行了重大调整，以下操作均基于 V4.x 规范。

1. 恢复前准备（针对恢复操作）

在进行物理恢复前，必须为目标租户准备充足的资源。

• 检查原租户信息：记录原始租户的资源配置（Unit Config）、资源池、`PRIMARY_ZONE`、`LOCALITY` 等信息。
• 创建目标资源：在目标集群中创建与原租户相同或更高的资源单元和资源池。
• 确保版本兼容：确认备份集的版本与目标集群的版本相互兼容（详阅官方"恢复前准备"章节）。

-- 1. 创建资源单元（需符合集群现有资源规格）
        CREATE RESOURCE UNIT restore_unit MAX_CPU 8, MEMORY_SIZE '16G';

        -- 2. 创建资源池（分布在三个 Zone）
        CREATE RESOURCE POOL restore_pool UNIT='restore_unit', UNIT_NUM=1, ZONE_LIST=('zone1','zone2','zone3');

2. 配置备份与归档目的端

V4.x 版本不再支持通过配置项（如 backup_dest）来设置备份目的端，而是使用 ALTER SYSTEM 语句为租户独立配置路径。

日志归档路径（LOG_ARCHIVE_DEST）

日志归档路径的配置支持 LOCATION、BINDING 和 PIECE_SWITCH_INTERVAL 参数。

• LOCATION：指定备份路径，支持 NFS（file://）或 OSS 等对象存储，且路径必须为独立空目录，不同租户不可共用。
• BINDING：设置归档与业务的优先模式。MANDATORY 表示归档失败会阻塞用户写入（强同步），OPTIONAL 则不会阻塞。
• PIECE_SWITCH_INTERVAL：按天切分 Piece 目录，方便管理 PITR。

-- 系统租户为业务租户 mysql_tenant 配置归档路径
        ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=file:///data/backup/tenant1/clog BINDING=Optional PIECE_SWITCH_INTERVAL=1d' TENANT=mysql_tenant;

        -- 用户租户为自身配置归档路径
        ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=file:///data/backup/tenant1/clog BINDING=Optional PIECE_SWITCH_INTERVAL=1d';

-- 查看租户的归档路径配置（系统租户查看所有租户）
        SELECT TENANT_ID, DEST_ID, VALUE FROM oceanbase.CDB_OB_ARCHIVE_DEST;

        -- 用户租户查看本租户的归档配置
        SELECT DEST_ID, NAME, VALUE FROM oceanbase.DBA_OB_ARCHIVE_DEST;

数据备份路径（DATA_BACKUP_DEST）

数据备份路径的配置需指定存储介质与路径。目前支持 NFS 和 阿里云 OSS 等对象存储。

-- 系统租户为 mysql_tenant 配置 NFS 备份路径
        ALTER SYSTEM SET DATA_BACKUP_DEST = 'file:///data/backup/data' TENANT = mysql_tenant;

        -- 系统租户为 mysql_tenant 配置 OSS 备份路径
        ALTER SYSTEM SET DATA_BACKUP_DEST = 'oss://oceanbase-test-bucket/backup/data?host=xxx.aliyun-inc.com&access_id=****&access_key=****' TENANT = mysql_tenant;

        -- 用户租户为自身配置备份路径
        ALTER SYSTEM SET DATA_BACKUP_DEST = 'file:///data/backup/data';

3. 开启日志归档（ARCHIVELOG）

完成归档路径配置后，必须为租户开启 归档模式（ARCHIVELOG），数据备份才能进行。归档模式的开启权限要求为 root@sys 或各租户的管理员用户。

-- 系统租户为集群内所有用户租户开启归档
        ALTER SYSTEM ARCHIVELOG TENANT = all;

        -- 系统租户为特定租户 mysql_tenant 开启归档
        ALTER SYSTEM ARCHIVELOG TENANT = mysql_tenant;

        -- 用户租户为本租户开启归档
        ALTER SYSTEM ARCHIVELOG;

如需关闭归档模式，可使用 NOARCHIVELOG 命令。但请注意，关闭后，正在进行的归档任务将停止，且无法发起数据备份。

-- 系统租户为用户租户 mysql_tenant 关闭归档模式
        ALTER SYSTEM NOARCHIVELOG TENANT = mysql_tenant;

4. 发起数据备份（BACKUP DATABASE / TENANT）

V4.x 版本的数据备份分为全量备份和增量备份两种类型。在执行数据备份前，务必确保目标租户的归档模式已开启且处于 DOING 状态。

全量备份（Full Backup）

• 系统租户为所有用户租户发起全量备份：ALTER SYSTEM BACKUP DATABASE;
• 系统租户为指定租户 mysql_tenant 发起全量备份：ALTER SYSTEM BACKUP TENANT = mysql_tenant;
• 用户租户为本租户发起全量备份：ALTER SYSTEM BACKUP DATABASE;

-- 系统租户仅为租户 mysql_tenant 发起全量数据备份
        ALTER SYSTEM BACKUP TENANT = mysql_tenant;

        -- 用户租户（mysql_tenant 管理员）为本租户发起全量备份
        ALTER SYSTEM BACKUP DATABASE;

增量备份（Incremental Backup）

备份上一次备份后修改的宏块。如果在没有全量数据备份的情况下直接发起增量备份，系统会将增量备份转换为全量备份。同样，集群升级到高版本后，即使低版本中已执行全量备份，直接发起增量备份默认也会转为全量备份。

-- 系统租户为租户 mysql_tenant 发起增量备份
        ALTER SYSTEM BACKUP INCREMENTAL TENANT = mysql_tenant;

        -- 用户租户为本租户发起增量备份
        ALTER SYSTEM BACKUP INCREMENTAL DATABASE;

-- 全量备份 + 日志
        ALTER SYSTEM BACKUP TENANT = mysql_tenant PLUS ARCHIVELOG;

5. 监控数据备份与归档进度

OceanBase 提供了丰富的监控视图，帮助 DBA 实时跟踪备份任务。

监控数据备份

• JOB 级任务（CDB_OB_BACKUP_JOBS / DBA_OB_BACKUP_JOBS）：每次备份命令对应一条 JOB 记录，记录任务整体状态。STATUS 字段反映了当前任务的执行阶段，RESULT 和 COMMENT 字段用于记录执行结果和错误信息，便于排查。
• TASK 级任务（CDB_OB_BACKUP_TASKS / DBA_OB_BACKUP_TASKS）：每个备份集对应一个 TASK 记录，包含更细粒度的进度，如已备份的宏块数（FINISH_MACRO_BLOCK_COUNT），以及数据/日志进度百分比。

-- 系统租户查看所有租户的 JOB 级备份进度
        SELECT * FROM oceanbase.CDB_OB_BACKUP_JOBS\G

        -- 用户租户查看本租户的 TASK 级备份进度
        SELECT TASK_ID, STATUS, START_TIMESTAMP, FINISH_MACRO_BLOCK_COUNT, DATA_PROGRESS 
        FROM oceanbase.DBA_OB_BACKUP_TASKS;

监控日志归档

通过 CDB_OB_ARCHIVELOG 视图可查看每个租户每个日志流的归档位点和 Piece 状态。对于租户级监控，可使用 DBA_OB_ARCHIVELOG 视图。

-- 系统租户查看日志归档进度
        SELECT TENANT_ID, LS_ID, BEGIN_SCN_DISPLAY, END_SCN_DISPLAY, STATUS 
        FROM oceanbase.CDB_OB_ARCHIVELOG;

6. 执行物理恢复（RESTORE）

物理恢复是一种租户级操作，既支持在同集群内恢复，也支持跨集群恢复。OceanBase 数据库支持租户级别的基于时间点的全量恢复/快速恢复。

恢复前准备

• 在目标集群中为新租户创建资源池。
• 确保备份路径的完整性和可访问性。

（可选）使用 PREVIEW 预检恢复

在执行 RESTORE 之前，可以通过 ALTER SYSTEM RESTORE...PREVIEW 预检恢复所需的 backup_set 和 archivelog_piece。

-- 1. 预检恢复所需备份集（示例：恢复到指定 SCN）
        ALTER SYSTEM RESTORE FROM 'file:///data/backup/data, file:///data/backup/archive' UNTIL SCN = 1712650554000909004 PREVIEW;

        -- 2. 执行成功后查看结果
        SHOW RESTORE PREVIEW;

执行恢复语句

• uri：由数据备份路径和日志归档路径组成，英文逗号分隔。
• pool_list：待恢复的新租户所绑定的资源池，多个资源池用英文逗号分隔。
• locality/primary_zone：建议尽量与源租户保持同构。
• concurrency：物理恢复的并行度，可根据硬件资源调整。
• method：恢复模式，full（全量恢复）或 quick（快速恢复）。

-- 示例：将 mysql_tenant 恢复到新租户 new_mysql，恢复到时间点 2024-06-01 00:00:00
        ALTER SYSTEM RESTORE new_mysql
        FROM 'file:///data/backup/data, file:///data/backup/archive'
        UNTIL TIME = '2024-06-01 00:00:00'
        WITH 'pool_list=restore_pool&locality=F@zone1,F@zone2,F@zone3&primary_zone=zone1&concurrency=10&method=full';

ALTER SYSTEM ACTIVATE STANDBY TENANT = new_mysql;

7. 查看恢复状态与结果

可以通过以下视图监控和确认恢复任务的进度与最终结果：

• CDB_OB_RESTORE_PROGRESS：展示进行中的恢复任务进度。
• CDB_OB_RESTORE_HISTORY：展示已完成的恢复任务结果，COMMENT 字段记录任务失败时的错误信息。
• DBA_OB_TENANTS：查询恢复后的租户信息，RESTORE_DATA_MODE 列为物理恢复相关信息。

-- 查看恢复进度
        SELECT * FROM oceanbase.CDB_OB_RESTORE_PROGRESS\G

        -- 查看恢复结果历史
        SELECT * FROM oceanbase.CDB_OB_RESTORE_HISTORY\G

        -- 在目标新租户中验证数据完整性
        -- 例如，对比原租户与新租户的表结构和行数

8. 配置备份清理策略

为避免备份数据过多占用存储空间，OceanBase 支持自动清理过期备份。V4.x 版本不再支持通过配置项 backup_recovery_window 来设置，而是使用 ALTER SYSTEM ADD DELETE BACKUP POLICY 语句配置清理策略。

-- 设置备份保留最近 7 天（系统租户为指定租户设置）
        ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d' TENANT = mysql_tenant;

        -- 用户租户为本租户设置保留策略
        ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d';

        -- 查看已配置的清理策略
        SELECT * FROM oceanbase.DBA_OB_BACKUP_DELETE_POLICY;

        -- 手动触发清理（如需要）
        ALTER SYSTEM DELETE BACKUP;

PITR（Point-in-Time Recovery，时间点恢复） 是 OceanBase 数据库物理备份的核心能力，允许将数据恢复到任意历史时间点，是应对数据误操作（如误删表、误更新）的关键手段。PITR 依赖于全量/增量数据备份 + 完整的日志归档两部分：全量备份提供基线数据，增量备份捕获变化数据，日志归档则持续记录 Redo 日志，三者结合可实现任意时间点的精确恢复。

增量备份（Incremental Backup）

在 OceanBase 数据库中，增量备份是提高备份效率、降低存储开销的关键机制，也是实现高效 PITR 的重要基础。

定义与原理

增量备份是指备份上一次备份以后新增和修改过的宏块（Macroblock），而全量备份则备份所有的宏块。

• 备份内容：一次增量备份 = 全量元信息的备份 + 增量的数据宏块备份。
• 核心依赖：OceanBase 数据库的基线宏块具有全局唯一的逻辑标识（Logical Identifier），该标识提供了增量备份重用宏块的能力，使得增量备份在不同 backup_set 之间读取宏块时能够高效复用。
• 性能对比：增量备份的恢复和全量备份的恢复在流程上基本一致，性能上也没有差别，只是会根据逻辑标识在不同的 backup_set 之间读取宏块。

增量备份的触发与行为

OceanBase 提供 ALTER SYSTEM BACKUP INCREMENTAL 语句用于发起增量备份。

-- 系统租户为所有用户租户发起增量备份
        ALTER SYSTEM BACKUP INCREMENTAL DATABASE;

        -- 系统租户为指定租户发起增量备份
        ALTER SYSTEM BACKUP INCREMENTAL TENANT = mysql_tenant;

        -- 用户租户为本租户发起增量备份
        ALTER SYSTEM BACKUP INCREMENTAL DATABASE;

PITR 恢复前的准备与约束

在进行 PITR 前，需完成以下准备工作并了解约束限制：

1. 可恢复区间判断

恢复位点 timestamp 或 SCN 需要满足以下约束：

• 大于等于数据备份视图 CDB_OB_BACKUP_SET_FILES 中记录的数据备份的最小恢复位点 MIN_RESTORE_SCN；
• 小于等于日志归档视图 CDB_OB_ARCHIVELOG 中的最大归档位点 CHECKPOINT_SCN；
• 由于日志归档可能出现断流，因此恢复位点的选择还需要考虑日志归档的不连续区间，对于可恢复区间的选择则可能是分段的。

2. 时区注意事项

对于指定时间戳的恢复方式，OceanBase 数据库将根据备份集中最新记录的时区将时间戳转换成对应的 SCN，此处的时区来源于备份租户的系统变量 system_time_zone，其默认值为 CST（即中国标准时间，+8:00），并保存在备份集的 locality_info.obbak 文件中。

3. 恢复前准备清单

• 在目标集群中为待恢复的新租户创建资源池（建议与源租户保持同构）。
• 如备份时设置了加密密码，需在执行恢复前使用 SET DECRYPTION IDENTIFIED BY 'password' 设置解密密码。
• 如源租户配置了透明加密，还需设置 KMS 加密信息。
• 确保备份目的端（NFS/OSS）可访问且路径正确。

执行 PITR 恢复

OceanBase 支持三种恢复方式：恢复到指定时间戳、恢复到指定 SCN、恢复到最新位点。恢复命令由 root@sys 租户执行。

📌 恢复命令语法

-- 恢复到指定时间戳（推荐方式，精确到秒）
        ALTER SYSTEM RESTORE dest_tenant_name 
            FROM uri 
            UNTIL TIME = 'timestamp' 
            WITH 'restore_option' 
            [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] 
            [DESCRIPTION [=] description];

        -- 恢复到指定 SCN
        ALTER SYSTEM RESTORE dest_tenant_name 
            FROM uri 
            UNTIL SCN = scn 
            WITH 'restore_option' 
            [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] 
            [DESCRIPTION [=] description];

        -- 恢复到最新位点
        ALTER SYSTEM RESTORE dest_tenant_name 
            FROM uri 
            WITH 'restore_option' 
            [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] 
            [DESCRIPTION [=] description];

📌 参数详解

📌 恢复命令示例

-- 示例1：恢复到指定时间点
        ALTER SYSTEM RESTORE new_mysql
            FROM 'file:///data/backup/data,file:///data/backup/archive'
            UNTIL TIME = '2024-06-01 00:00:00'
            WITH 'pool_list=restore_pool&locality=F@zone1,F@zone2,F@zone3&primary_zone=zone1&concurrency=8&method=full';

        -- 示例2：恢复到最新位点
        ALTER SYSTEM RESTORE new_mysql
            FROM 'file:///data/backup/data,file:///data/backup/archive'
            WITH 'pool_list=restore_pool&locality=F@zone1,F@zone2,F@zone3&concurrency=8';

        -- 示例3：恢复单个表到指定时间点（V4.x 支持）
        ALTER SYSTEM RECOVER TABLE USER01.TEST1 TO TENANT new_mysql
            FROM 'file:///obbackup/ob4zry/1699999999/tenant_incarnation_1/1002/data,file:///obbackup/ob4zry/1699999999/tenant_incarnation_1/1002/clog'
            UNTIL TIME='2024-05-23 18:00:00'
            WITH 'pool_list=restore_pool1&concurrency=8';

📌 使用 PREVIEW 预检恢复

在执行恢复前，可以通过 RESTORE PREVIEW 预检恢复所需的 backup_set 和 archivelog_piece。

-- 预检恢复到指定 SCN
        ALTER SYSTEM RESTORE FROM 'file:///ob_backup/data, file:///ob_backup/archive' 
            UNTIL SCN = 1712650554000909004 PREVIEW;

        -- 预检恢复到指定时间戳
        ALTER SYSTEM RESTORE FROM 'file:///ob_backup/data, file:///ob_backup/archive' 
            UNTIL TIME = '2024-04-09 16:15:54' PREVIEW;

        -- 查看预检结果
        SHOW RESTORE PREVIEW;

恢复性能调优

OceanBase 提供了专门的配置项来加速恢复过程：

• ha_high_thread_score：设置数据恢复任务队列使用的工作线程数。在待恢复租户对应的 Meta 租户创建成功后，可通过此配置项加速恢复。
• log_restore_concurrency：设置日志恢复的并发数。

-- 在 sys 租户中为指定租户设置恢复并发线程数
        ALTER SYSTEM SET ha_high_thread_score = 10 TENANT = mysql;

        -- 设置日志恢复并发数（0 表示使用自适应默认值）
        ALTER SYSTEM SET log_restore_concurrency = 4 TENANT = mysql;

恢复可观测性

OceanBase 提供了完善的恢复监控视图：

• CDB_OB_RESTORE_PROGRESS：展示各租户恢复的进度（系统租户）。
• DBA_OB_RESTORE_PROGRESS：展示正在进行的恢复任务（用户租户）。
• CDB_OB_RESTORE_HISTORY：展示各租户的恢复结果，是恢复任务结束时对应记录的快照。
• DBA_OB_RESTORE_HISTORY：展示已完成的恢复任务。

-- 查看恢复进度（系统租户）
        SELECT * FROM oceanbase.CDB_OB_RESTORE_PROGRESS\G

        -- 查看恢复历史结果
        SELECT TENANT_ID, RESTORE_TENANT_NAME, RESTORE_SCN_DISPLAY, 
            STATUS, START_TIMESTAMP, FINISH_TIMESTAMP, COMMENT
        FROM oceanbase.CDB_OB_RESTORE_HISTORY
        ORDER BY FINISH_TIMESTAMP DESC;

        -- 查看恢复后的租户基本信息
        SELECT TENANT_ID, TENANT_NAME, RESTORE_DATA_MODE 
        FROM oceanbase.DBA_OB_TENANTS;

备份清理策略与 PITR 窗口的关系

备份数据的保留策略与 PITR 的能力密切相关：

• RECOVERY_WINDOW 策略：设置备份数据可恢复的时间窗口，例如 RECOVERY_WINDOW '7d' 表示从当前时间往前推 7 天内的数据保证可恢复。超过该窗口且与窗口内恢复无关的备份数据将被视为过期并自动清理。
• RETENTION 策略：设置备份数据的绝对保留时长，例如 RETENTION 30 DAYS 表示保留最近 30 天的备份数据。

-- 设置恢复窗口策略（保证过去 7 天数据可恢复）
        ALTER SYSTEM ADD DELETE BACKUP POLICY 'pitr_policy' RECOVERY_WINDOW '7d';

        -- 设置绝对保留时长策略
        ALTER SYSTEM ADD DELETE BACKUP POLICY 'retention_policy' RETENTION 30 DAYS;

        -- 查看已配置的清理策略
        SELECT * FROM oceanbase.DBA_OB_BACKUP_DELETE_POLICY;

定期执行备份集校验和恢复演练是保障数据安全的最后一道防线。备份集校验用于确保备份数据的完整性和有效性；恢复演练则通过定期执行完整的恢复测试，验证备份数据的实际可恢复性，确保在真正的灾难发生时能够可靠地完成数据恢复。OceanBase 提供了多层次的校验机制和丰富的监控视图，帮助 DBA 构建企业级的数据安全验证体系。

备份集校验概述

OceanBase 数据库的备份数据校验主要检查数据的有效性和完整性。有效性校验通过计算数据校验和（Checksum）来识别数据文件中的比特位翻转；完整性校验检查数据文件的完整性。备份校验的操作是在备份数据的基础上扫描并计算其数据，并不真正恢复数据，因此消耗的资源较少、校验速度快，适合作为日常巡检手段。

校验类型

执行要求： 数据校验和恢复命令必须在 sys 租户中执行。[reference:10]

• 集群级校验：校验当前集群的所有备份集和对应的日志归档数据。执行 ALTER SYSTEM VALIDATE DATABASE; 即可启动。[reference:11]
• 备份集校验：仅校验指定的备份集（BackupSet），不校验日志归档数据。
• 日志校验：仅校验指定的日志备份片（BackupPiece）。日志在分裂成 Piece 后，可通过此命令进行校验。

-- 校验当前集群的所有备份集和对应日志
        ALTER SYSTEM VALIDATE DATABASE;

        -- 校验指定的备份集
        ALTER SYSTEM VALIDATE BACKUPSET 1;

        -- 校验指定的日志备份片
        ALTER SYSTEM VALIDATE BACKUPPIECE 2;

备份介质预检：test_io_device

在配置备份路径后、正式执行备份前，可以使用 ob_admin test_io_device 命令提前验证备份介质的 I/O 接口和权限是否满足备份恢复的需要。这是一个极其重要的预防性检查步骤，可避免在执行正式备份时才发现介质不可访问。[reference:12]

-- 测试 NFS 路径
        ./ob_admin test_io_device -d'file:///data/nfs'

        -- 测试 OSS 路径
        ./ob_admin test_io_device -d'oss://home/admin/backup_info' 
            -s'host=http://oss-cn-hangzhou.aliyuncs.com&access_id=111&access_key=222'

校验监控视图

OceanBase 提供了完整的备份校验监控视图体系，帮助 DBA 实时跟踪校验任务的进度和结果。

视图清单

查询示例

-- 查看当前校验任务进度
        SELECT JOB_ID, STATUS, RESULT, START_TIMESTAMP 
        FROM oceanbase.CDB_OB_BACKUP_VALIDATION_JOB;

        -- 查看校验任务详情（已完成 Partition Group 个数等进度信息）
        SELECT JOB_ID, TASK_ID, BACKUP_SET_ID, STATUS, RESULT,
            FINISH_PG_COUNT, TOTAL_PG_COUNT, 
            FINISH_PARTITION_COUNT, TOTAL_PARTITION_COUNT
        FROM oceanbase.CDB_OB_TENANT_BACKUP_VALIDATION_TASK;

        -- 查看历史校验结果
        SELECT * FROM oceanbase.CDB_OB_BACKUP_VALIDATION_JOB_HISTORY
        ORDER BY START_TIMESTAMP DESC LIMIT 10;

OCP 自动化恢复抽检策略

OceanBase Cloud Platform（OCP）提供了自动化的恢复抽检功能，可以在备份完成后自动、定期地验证备份数据的可恢复性，无需人工干预，显著提升备份验证的效率和质量。[reference:16]

核心流程

1. 配置恢复抽检策略，指定抽样的时间范围、备份模式（物理备份/逻辑备份）等。
2. OCP 每天在指定时间范围内以随机顺序对已做过数据备份的租户依次进行恢复测试。[reference:17]
3. OCP 自动将备份数据恢复到目标集群的临时租户中。
4. 验证完成后，OCP 自动删除临时恢复租户，不产生资源遗留。[reference:18]

恢复演练完整流程

恢复演练的核心步骤包括：恢复前资源准备、确定恢复时间点、执行恢复、验证恢复后数据完整性、演练后清理。以下以恢复租户到指定时间点为例演示。

演练前准备

• 在目标集群中创建资源单元和资源池（规格不低于源租户）
• 确保备份介质（NFS/OSS）可正常访问
• 记录原租户的关键配置（Locality、Primary Zone 等）

-- 创建演练用的资源单元和资源池
        CREATE RESOURCE UNIT drill_unit MAX_CPU 8, MEMORY_SIZE '16G';
        CREATE RESOURCE POOL drill_pool UNIT='drill_unit', 
            UNIT_NUM=1, ZONE_LIST=('zone1','zone2','zone3');

执行 PITR 恢复

-- 恢复到演练时间点（建议选择演练窗口内的一个历史时间点）
        ALTER SYSTEM RESTORE drill_tenant
            FROM 'file:///data/backup/data,file:///data/backup/archive'
            UNTIL TIME = '2025-06-12 10:00:00'
            WITH 'pool_list=drill_pool&locality=F@zone1,F@zone2,F@zone3&primary_zone=zone1';

数据一致性验证

恢复完成后，需要在新租户中验证数据完整性和正确性。核心验证方法：

• 表行数对比：对比源租户与恢复租户中关键表的行数是否一致。
• 抽样数据比对：选取典型表抽样查询，验证数据是否正确恢复。
• 业务功能验证：执行典型业务 SQL，验证恢复后的数据能否满足业务功能。
• 校验和验证：通过计算表数据的校验和进行快速比对（MySQL 模式可用 CHECKSUM TABLE）。[reference:21]

-- 在 MySQL 模式下执行校验和比对
        CHECKSUM TABLE orders;

        -- 抽样验证典型数据
        SELECT COUNT(*) FROM orders WHERE order_date >= '2025-06-01';

恢复演练频率与策略建议

• 核心业务租户：建议每 季度 执行一次完整恢复演练。
• 普通业务租户：建议每 半年 执行一次恢复演练。
• 备份介质或存储架构变更后：必须在变更完成后立即执行一次恢复演练。
• OceanBase 版本升级后：建议在新版本环境中执行恢复演练，验证跨版本兼容性。

执行计划（Execution Plan）是对一条 SQL 查询语句在数据库中执行过程的描述。它展示了优化器决定如何访问数据、以何种顺序连接表以及使用哪些连接算法等关键信息。理解执行计划是进行 SQL 调优的核心能力，通过分析执行计划可以快速定位性能瓶颈，确定优化方向。

执行计划的获取方式

OceanBase 数据库支持多种方式来查看 SQL 的执行计划，每种方式适用于不同的场景。

1️⃣ EXPLAIN 命令：获取逻辑执行计划

EXPLAIN 语句适用于 SELECT、DELETE、INSERT、REPLACE 和 UPDATE 等 SQL 语句，用于展示优化器所提供的有关语句执行计划的信息，包括如何处理该语句、如何联接表以及以何种顺序联接表等信息。EXPLAIN 命令不会实际执行 SQL，而是展示预估的执行计划，因此可以放心在生产环境执行。

OceanBase 数据库支持三种 EXPLAIN 模式，展示不同详细程度的执行计划信息：

-- BASIC 模式示例
        EXPLAIN BASIC SELECT * FROM orders WHERE order_id = 10086;

        -- 默认模式示例
        EXPLAIN SELECT * FROM orders o, customers c 
        WHERE o.cust_id = c.cust_id AND o.order_id = 10086;

        -- EXTENDED 模式示例
        EXPLAIN EXTENDED SELECT * FROM orders WHERE order_date > '2025-01-01';

        -- 为 EXPLAIN 计划设置标记信息，便于后续跟踪
        EXPLAIN SET STATEMENT_ID='test_plan' SELECT * FROM orders;

2️⃣ DBMS_XPLAN 系统包：查看历史执行计划和实际执行信息

DBMS_XPLAN 是 OceanBase 数据库提供的系统包，用于查询逻辑执行计划及历史执行计划的详细信息。OceanBase 数据库会保存用户执行过的所有查询的计划，包括物理计划以及逻辑计划，用户后续排查问题使用。

• DISPLAY()：显示通过 EXPLAIN 命令生成的逻辑执行计划。
• DISPLAY_CURSOR()：显示已执行的查询计划详细信息，反映了 SQL 在计划缓存中的真实执行计划，适用于查看已执行 SQL 的实际计划。在 MySQL 租户中，需在 SELECT 语句中直接调用该函数来输出计划信息[reference:10]。
• DISPLAY_ACTIVE_SESSION_PLAN()：显示指定会话中正在执行或刚执行完的 SQL 的实时计划详情，适合排查正在运行的慢查询。

-- 使用 DBMS_XPLAN 查看通过 EXPLAIN 生成的计划
        SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE', 'test_plan', 'TYPICAL'));

        -- 通过 SQL_ID 查看计划缓存中的实际执行计划
        SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('abc123def456'));

        -- 查看当前会话中最后一条 SQL 的实际执行计划
        SELECT DBMS_XPLAN.DISPLAY_CURSOR();

3️⃣ 实时执行计划展示：查询计划缓存中的物理执行计划

由于统计信息变化或 Session 变量设置变化，EXPLAIN 生成的逻辑执行计划可能与 SQL 实际执行时使用的物理执行计划不同。为了确定 SQL 在系统中实际使用的执行计划，可以通过查询计划缓存视图来获取。

在 OceanBase 数据库中，查询 SQL 实际物理执行计划的核心视图是 GV$OB_PLAN_CACHE_PLAN_EXPLAIN。该视图用于展示缓存在全部的 OBServer 节点中的计划缓存中的物理执行计划，从 V4.0.0 版本开始引入[reference:11]。

• GV$OB_PLAN_CACHE_PLAN_STAT：记录每个执行计划的统计信息，包括执行次数、平均耗时等。
• GV$OB_PLAN_CACHE_PLAN_EXPLAIN：记录每个执行计划的形状（算子树结构），展示完整的物理执行计划。该视图仅支持 GET 操作，查询时需指定 TENANT_ID 和 PLAN_ID 字段[reference:12]。

-- 第1步：查询特定 SQL 在计划缓存中的 plan_id
        SELECT TENANT_ID, PLAN_ID, SQL_ID, QUERY_SQL
        FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT
        WHERE QUERY_SQL LIKE '%orders%' AND QUERY_SQL NOT LIKE '%GV$OB_PLAN_CACHE%'
        LIMIT 1;

        -- 第2步：根据 plan_id 查询物理执行计划详情
        SELECT OPERATOR, NAME, ROWS, COST 
        FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_EXPLAIN
        WHERE TENANT_ID = 1002 AND PLAN_ID = 123;

        -- 查看所有 OBServer 节点上的计划缓存统计
        SELECT * FROM oceanbase.GV$OB_PLAN_CACHE_STAT;

执行计划的阅读与理解

OceanBase 数据库的执行计划本质上是由物理操作符构成的一棵执行树，物理操作符一般对应一个关系操作，如表扫描、联接、聚合、排序等。通过将不同的物理操作符按照一定的先后顺序组织在一棵执行树中，最终完成整个 SQL 语句。

执行计划输出字段详解

OceanBase 执行计划输出的关键列字段及其含义：

核心算子介绍

执行计划由各种物理操作符（算子）构成，掌握常用算子的含义是阅读执行计划的基础。

表访问算子

• TABLE SCAN（全表扫描/范围扫描）：对表进行全表扫描或索引范围扫描，返回 0 行或多行数据。当查询没有可用索引时通常使用此算子。
• TABLE GET（主键定位）：通过主键或唯一键直接定位数据，返回 0 行或 1 行数据，是最高效的表访问方式。
• TABLE LOOKUP（回表）：使用二级索引扫描后，根据索引中的主键回表查询完整的行数据。

JOIN 算子

OceanBase 数据库支持的 JOIN 算子主要有三种：

• NESTED-LOOP JOIN（NLJ，嵌套循环连接）：对左表（驱动表）的每一行，在右表（被驱动表）中查找匹配的行。当左表数据量较小且右表连接键上有高效索引时性能较好[reference:14]。
• MERGE JOIN（MJ，归并连接）：先将两个表按照连接键排序，然后同时扫描合并。适用于两表数据量都较大且连接键已排序的场景。
• HASH JOIN（HJ，哈希连接）：构建右表的哈希表，然后扫描左表进行探查。适合大表连接且无索引的场景。HASH JOIN 和 MERGE JOIN 仅适用于等值 JOIN 条件[reference:15]。

-- 强制使用 NESTED-LOOP JOIN 的 Hint 示例
        SELECT /*+ LEADING(t1 t2) USE_NL(t2) */ * 
        FROM t1, t2 
        WHERE t1.id = t2.id;

排序与聚合算子

• SORT / TOP-N SORT：对数据进行排序操作。TOP-N SORT 是带 LIMIT 的排序优化，只保留前 N 行。
• HASH GROUP BY / MERGE GROUP BY：对数据进行分组聚合操作，如 COUNT(*)、SUM(col) 等。

其他常用算子

• LIMIT：限制返回的行数，通常会与其他算子配合，优化 LIMIT 查询。
• MATERIAL：物化算子，将子查询的结果临时保存，避免重复扫描。常见于 NESTED-LOOP JOIN 的右表需要重复扫描的场景[reference:16]。
• SUBPLAN FILTER：子计划过滤算子，用于驱动表达式中的子查询执行。左边取一行数据，然后执行右边的子计划。
• EXCHANGE IN/OUT：分布式执行时的数据交换算子，用于并行查询中的数据重分布。
• WINDOW FUNCTION：窗口函数算子，用于实现 SQL 中的分析函数（如 ROW_NUMBER()、RANK() 等），计算窗口下的相关行的结果。

统计信息与预估行数分析

优化器生成的执行计划往往基于代价来评估，而统计信息是否准确直接影响算子的行数估算，进而影响计划的选择。统计信息准确，优化器能够准确评估各执行计划的代价，从而选出最优执行计划；反之则可能选择低效计划，导致 SQL 性能问题[reference:17]。

预估行数 vs 实际行数

• 统计信息过期：如果表的数据量发生较大变化后未及时收集统计信息，预估行数可能与实际行数产生较大偏差，可能导致优化器选择了不合适的执行计划。
• 数据分布不均：对于存在数据倾斜的列，若未收集直方图信息，优化器可能无法准确估算行数。
• 复杂表达式：WHERE 条件中包含复杂函数或隐式类型转换时，优化器的行数估算可能不准确。
• Runtime Filter 影响：当计划启用并行计划并开启 JOIN FILTER 时（如 set global runtime_filter_type ='range,in,bloom_filter'），也可能出现估算的行数和实际的行数差距较大的情况。

如何分析统计信息准确性

通过执行计划可以分析统计信息是否有使用，以及统计信息是否过期：

-- 查看表的统计信息最后更新时间
        SELECT TABLE_NAME, LAST_ANALYZED, NUM_ROWS, AVG_ROW_LEN 
        FROM oceanbase.DBA_TABLES 
        WHERE OWNER = 'TESTDB' AND TABLE_NAME IN ('ORDERS', 'CUSTOMERS');

        -- 查看列的直方图信息
        SELECT COLUMN_NAME, NUM_DISTINCT, HISTOGRAM 
        FROM oceanbase.DBA_TAB_COL_STATISTICS 
        WHERE OWNER = 'TESTDB' AND TABLE_NAME = 'ORDERS';

        -- 手动收集统计信息（支持 ANALYZE 命令和 DBMS_STATS 系统包两种方式）
        ANALYZE TABLE orders COMPUTE STATISTICS;
        -- 或使用 DBMS_STATS 系统包（推荐在 V4.x 中使用）
        CALL DBMS_STATS.GATHER_TABLE_STATS('TESTDB', 'ORDERS');
        ANALYZE TABLE orders UPDATE HISTOGRAM ON order_status, customer_id;

SQL 调优基本流程

OceanBase 数据库的 SQL 调优遵循系统化的诊断流程：

1. 查找慢 SQL：通过 GV$OB_SQL_AUDIT（SQL 审计表）查找耗时较长或消耗资源较高的 SQL 语句。
2. 获取实际执行计划：通过 GV$OB_PLAN_CACHE_PLAN_EXPLAIN 获取 SQL 在计划缓存中的实际物理执行计划，而非仅靠 EXPLAIN 的预估计划。
3. 分析执行计划形状：关注关键算子类型（是否有全表扫描、连接顺序是否合理、是否使用了正确的索引）、预估行数是否准确、是否涉及分布式数据重分布等。
4. 收集最新统计信息：若统计信息过旧，执行统计信息收集命令更新。
5. 优化 SQL：根据分析结果进行优化——创建合适索引、改写 SQL（避免复杂函数、优化连接顺序、使用分区裁剪等）、使用 Hint 绑定执行计划、应用 Outline 固定执行计划等。
6. 验证优化效果：通过再次执行并比较执行计划差异来验证优化效果。

-- 查找最近 1 小时内的慢 SQL（执行时间 > 500ms）
        SELECT SQL_ID, QUERY_SQL, ELAPSED_TIME, PLAN_TYPE, RET_CODE
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE REQUEST_TIME > UNIX_TIMESTAMP() * 1000000 - 3600000000
        AND ELAPSED_TIME > 500000
        ORDER BY ELAPSED_TIME DESC
        LIMIT 10;

        -- 查看 SQL 在计划缓存中的执行统计信息
        SELECT PLAN_ID, SQL_ID, AVG_EXE_TIME_US, EXECUTIONS
        FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT
        WHERE SQL_ID = 'abc123def456';

优化器统计信息（Optimizer Statistics）是描述数据库中表、列和索引等对象特征的数据集合，是优化器进行执行计划代价评估的核心依据。准确的统计信息能够帮助优化器正确估算SQL执行的行数、成本和数据分布，从而选择最优的执行计划；而统计信息过期或不准确则可能导致优化器选择低效的执行计划，严重影响SQL性能。

统计信息的类型

在 OceanBase 数据库优化器中，统计信息主要分为四大类：

直方图详解

直方图（Histogram）是一种特殊的列统计信息。默认情况下，优化器会假设列的数据分布是均匀的，并依据这一特征进行行数估算。但在真实场景中，大多数表的数据分布都存在倾斜，此时就需要直方图来描述数据分布特征，帮助优化器进行更准确的行数估计。

直方图类型

OceanBase 数据库优化器支持三种类型的直方图，收集时会根据列数据的真实分布特征自动选择合适的类型：

• 频率直方图（Frequency Histogram）：当列的 NDV 不超过 bucket_size（默认为 254）时，每个不同的列值对应直方图中的一个桶。此时直方图能精确记录每个值的出现频次，适用于基数较低的列。
• TopK 直方图（TopK Histogram）：当列的 NDV 超过 bucket_size 时，系统会计算一个阈值 p = (1 - (1/bucket_size)) * 100（默认 bucket_size=254，则 p ≈ 99.6%）。只有占据数据比例 ≥ 该阈值的热点值才会被作为桶保存，其余低频值被忽略。这种设计在有限桶数下尽可能保留高频值信息，降低了不必要的内存开销。
• 混合直方图（Hybrid Histogram）：前两种直方图的折中策略。它在满足最大桶数限制的同时，尽可能保留更多值的频次信息。当数据分布介于前两者之间时，优化器会自动选择混合直方图以达到信息保留与内存使用的平衡。

直方图监控视图

OceanBase 提供了多个视图用于查询直方图信息，支持 Oracle 和 MySQL 两种兼容模式：

• DBA_TAB_HISTOGRAMS / ALL_TAB_HISTOGRAMS：查询表列的直方图信息。
• DBA_PART_HISTOGRAMS：查询分区表分区级别的直方图信息。
• DBA_SUBPART_HISTOGRAMS：查询分区表子分区级别的直方图信息。

-- 查询指定列的直方图信息
        SELECT COLUMN_NAME, ENDPOINT_NUMBER, ENDPOINT_VALUE, ENDPOINT_REPEAT_COUNT
        FROM DBA_TAB_HISTOGRAMS
        WHERE OWNER = 'TEST' AND TABLE_NAME = 'ORDERS' AND COLUMN_NAME = 'ORDER_STATUS'
        ORDER BY ENDPOINT_NUMBER;

        -- 查看列的统计信息，包括直方图类型
        SELECT COLUMN_NAME, NUM_DISTINCT, HISTOGRAM, NUM_NULLS
        FROM DBA_TAB_COL_STATISTICS
        WHERE OWNER = 'TEST' AND TABLE_NAME = 'ORDERS';

统计信息的收集方式

OceanBase 数据库 V4.x 版本实现了全新的统计信息收集机制，将统计信息收集和每日合并解耦，每日合并不再收集统计信息。OceanBase 提供了多种统计信息收集方式，以适应不同场景的需求。

1️⃣ 自动收集（推荐）

自动统计信息收集任务基于 DBMS_SCHEDULER 系统包实现，以周为单位定义了周期性执行的维护窗口，集群环境为每个租户在每个维护窗口上都会有后台任务调度，OceanBase 会为每个租户按照调度时间表启动维护任务，在窗口中自动收集缺失或过期的统计信息。

收集范围与过期标准：自动收集针对的是统计信息缺失或统计信息过期的表，采用增量收集方式——只收集数据发生变化的分区，无需重新收集整个表的统计信息。统计信息过期的判断标准是分区上的 DML（增删改）变化量超过 STALE_PERCENT 阈值，默认值为 10%。

2️⃣ 手动收集

OceanBase 数据库优化器支持两种手动收集统计信息的方式：DBMS_STATS 系统包和 ANALYZE 命令行。

• DBMS_STATS 系统包（V4.x 推荐）：提供功能更丰富的统计信息收集能力，支持并行收集、分区表增量收集、统计信息历史管理等高级特性。
• ANALYZE 命令行：简单易用，在 Oracle 模式和 MySQL 模式下均可使用，适合快速收集统计信息。

-- 使用 DBMS_STATS 收集表级统计信息（推荐方式）
        -- 使用默认策略收集
        CALL DBMS_STATS.GATHER_TABLE_STATS('TEST', 'ORDERS');

        -- 不收集直方图
        CALL DBMS_STATS.GATHER_TABLE_STATS('TEST', 'ORDERS', 
            method_opt => 'FOR ALL COLUMNS SIZE 1');

        -- 指定并行度收集（大表加速）
        CALL DBMS_STATS.GATHER_TABLE_STATS('TEST', 'ORDERS', 
            DEGREE => 8, METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO');

        -- 指定列为直方图收集
        CALL DBMS_STATS.GATHER_TABLE_STATS('TEST', 'ORDERS', 
            METHOD_OPT => 'FOR COLUMNS ORDER_STATUS SIZE 254');

        -- 使用 ANALYZE 命令行收集
        ANALYZE TABLE orders COMPUTE STATISTICS;
        ANALYZE TABLE orders COMPUTE STATISTICS FOR ALL COLUMNS;
        ANALYZE TABLE orders COMPUTE STATISTICS FOR COLUMNS order_status;

3️⃣ 批量收集与分区表收集策略

对于 Schema 级别的批量统计信息收集，可使用 GATHER_SCHEMA_STATS；对于分区表，需根据数据变更模式选择增量或全局收集策略。

-- 收集整个 Schema 的统计信息
        CALL DBMS_STATS.GATHER_SCHEMA_STATS('TEST');

        -- 增量收集分区表（仅收集变更的分区）
        ALTER TABLE orders SET INCREMENTAL = TRUE;
        CALL DBMS_STATS.GATHER_TABLE_STATS('TEST', 'ORDERS', GRANULARITY => 'APPROX_GLOBAL AND PARTITION');

        -- 查询表的统计信息收集策略
        SELECT TABLE_NAME, INCREMENTAL, LAST_ANALYZED, STALE_STATS
        FROM DBA_TAB_STATISTICS
        WHERE OWNER = 'TEST';

统计信息收集策略配置（Prefs）

OceanBase 数据库优化器支持用户根据业务实际情况修改默认的收集策略（Prefs），以适应不同的业务场景和数据特征。

常用 Prefs 参数说明

Prefs 查询与修改

OceanBase 提供了一系列存储过程用于管理统计信息的收集策略。

-- 查询当前租户的 Prefs 设置
        SELECT DBMS_STATS.GET_PREFS('APPROXIMATE_NDV') FROM DUAL;
        SELECT DBMS_STATS.GET_PREFS('DEGREE') FROM DUAL;
        SELECT DBMS_STATS.GET_PREFS('METHOD_OPT') FROM DUAL;

        -- 查询指定表的 Prefs 设置
        SELECT DBMS_STATS.GET_PREFS('STALE_PERCENT', 'TEST', 'ORDERS') FROM DUAL;

        -- 设置租户级别的 Prefs（影响所有表）
        CALL DBMS_STATS.SET_GLOBAL_PREFS('APPROXIMATE_NDV', 'FALSE');
        CALL DBMS_STATS.SET_GLOBAL_PREFS('DEGREE', '8');

        -- 设置表级别的 Prefs（仅影响指定表）
        CALL DBMS_STATS.SET_TABLE_PREFS('TEST', 'ORDERS', 'DEGREE', '16');
        CALL DBMS_STATS.SET_TABLE_PREFS('TEST', 'ORDERS', 'STALE_PERCENT', '15');

        -- 删除表级别的 Prefs 设置（恢复使用全局默认值）
        CALL DBMS_STATS.DELETE_TABLE_PREFS('TEST', 'ORDERS', 'DEGREE');

        -- 还原全局所有 Prefs 为默认值
        CALL RESET_GLOBAL_PREF_DEFAULTS();

统计信息监控与诊断

核心监控视图

OceanBase 提供了丰富的视图用于查询统计信息收集状态和历史：

• DBA_TAB_STATISTICS：查询表级统计信息，包括最后收集时间、数据行数、是否过期等。
• DBA_TAB_COL_STATISTICS：查询 GLOBAL 级别的列级统计信息。
• DBA_PART_COL_STATISTICS：查询分区级别的列统计信息。
• DBA_OB_TASK_OPT_STAT_GATHER_HISTORY：统计信息收集任务的历史记录，用于排查自动或手动收集任务的执行情况。
• DBA_OB_TABLE_STAT_STALE_INFO：查询统计信息过期的表及过期原因（DML 变化统计、过期间隔）。

-- 查询统计信息过期的表（需要关注）
        SELECT OWNER, TABLE_NAME, OBJECT_TYPE, STALE_STATS, LAST_ANALYZED, NUM_ROWS
        FROM DBA_TAB_STATISTICS
        WHERE STALE_STATS = 'YES' AND OWNER = 'TEST';

        -- 查看最近自动收集任务的历史记录
        SELECT * FROM DBA_OB_TASK_OPT_STAT_GATHER_HISTORY
        WHERE START_TIME > DATE_SUB(NOW(), INTERVAL 7 DAY)
        ORDER BY START_TIME DESC
        LIMIT 20;

        -- 查询统计信息过期的表及过期详情
        SELECT TABLE_NAME, PARTITION_NAME, STALE_TYPE, STALE_PERCENT, LAST_ANALYZED
        FROM DBA_OB_TABLE_STAT_STALE_INFO
        WHERE OWNER = 'TEST';

统计信息收集问题排查

当发现自动统计信息收集任务未正常执行时，可通过以下步骤排查：

-- 步骤1：检查自动收集任务是否正常调度（系统租户查看）
        SELECT tenant_id AS failed_scheduler_tenant_id 
        FROM oceanbase.__all_tenant t 
        WHERE NOT EXISTS(SELECT 1 
            FROM oceanbase.__all_virtual_task_opt_stat_gather_history h 
            WHERE TYPE = 1 AND start_time > date_sub(now(), interval 1 day) 
            AND h.tenant_id = t.tenant_id);

        -- 步骤2：查询当前租户最近是否有失败的自动收集任务
        SELECT task_id, start_time, end_time, ret_code, stat_refresh_failed_list 
        FROM DBA_OB_TASK_OPT_STAT_GATHER_HISTORY 
        WHERE ret_code != 0 AND start_time > date_sub(now(), interval 1 day);

统计信息与执行计划缓存的关系

统计信息的更新会影响 Plan Cache 中缓存的执行计划。在 OceanBase 4.x 版本中，统计信息收集默认会刷新该表的 Plan Cache，意味着原先基于旧统计信息生成的执行计划可能被淘汰，下次执行时会根据新统计信息重新生成计划。此设计有助于保证执行计划的质量，但在业务高峰期进行手动统计信息收集需慎重评估影响。

• 收集统计信息后，可以通过 DBA_OB_TABLE_STAT_STALE_INFO 的 LAST_ANALYZED 字段，判定一个计划生成过程中使用的统计信息是否被更新。
• 如果统计信息被更新，OceanBase 默认会淘汰对应表在 Plan Cache 中包含的查询计划，强制在下一次执行时生成新的执行计划。

在 SQL 中添加 Hint 可以控制优化器按 Hint 指定的行为进行计划生成，该方法适用于系统上线前直接将 Hint 加入 SQL 中。但对于已上线的业务，如果出现优化器选择的计划不够优时，则需要在线进行计划绑定，即无需业务进行 SQL 更改，而是通过 DDL 操作将一组 Hint 加入到 SQL 中，从而使得优化器根据指定的一组 Hint 对该 SQL 生成更优计划。该组 Hint 称为 Outline（执行计划纲要）。通过对某条 SQL 创建 Outline，可保证该 SQL 在后续执行时始终使用指定的执行计划，避免因优化器选择不当导致性能波动。

创建 Outline

OceanBase 数据库支持通过两种方式创建 Outline：一种是通过 SQL_TEXT（用户执行的带参数的原始语句），另一种是通过 SQL_ID 创建。

📝 使用 SQL_TEXT 创建 Outline

使用 SQL_TEXT 创建 Outline 后，会生成一个 Key-Value 对存储在 Map 中，其中 Key 为绑定的 SQL 参数化后的文本，Value 为绑定的 Hint。语法如下：

CREATE [OR REPLACE] OUTLINE <outline_name> ON <stmt> [ TO <target_stmt> ];

参数说明：

• OR REPLACE：指定后，如果同名的 Outline 已存在，则会进行替换。
• stmt：一般为一个带有 Hint 和原始参数的 DML 语句。
• TO target_stmt：如果不指定，则表示如果数据库接受的 SQL 参数化后与 stmt 去掉 Hint 参数化文本相同，则将该 SQL 绑定 stmt 中 Hint 生成执行计划；如果期望对含有 Hint 的语句进行固定计划，则需要 TO target_stmt 来指明原始的 SQL。

⚠️ 重要约束：在使用 target_stmt 时，严格要求 stmt 与 target_stmt 在去掉 Hint 后完全匹配。

-- 创建测试表
        CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT, c3 INT, INDEX idx_c2(c2));
        INSERT INTO t1 VALUES(1, 1, 1), (2, 2, 2), (3, 3, 3);

        -- 查看默认执行计划（优化器选择全表扫描）
        EXPLAIN SELECT * FROM t1 WHERE c2 = 1;

        -- 创建 Outline 绑定索引计划
        CREATE OUTLINE otl_idx_c2 ON SELECT/*+ index(t1 idx_c2)*/ * FROM t1 WHERE c2 = 1;

        -- 使用 TO target_stmt 创建 Outline（针对含有 Hint 的原始 SQL 进行固定）
        CREATE OUTLINE outline1 ON SELECT /*+NO_REWRITE*/ * FROM tbl1 WHERE col1 = 4 AND col2 = 6 ORDER BY 2
            TO SELECT * FROM tbl1 WHERE col1 = 4 AND col2 = 6 ORDER BY 2;

上述示例来源：计划绑定-V4.3.5。

🔢 使用 SQL_ID 创建 Outline

使用 SQL_ID 创建 Outline 的语法如下：

CREATE OUTLINE outline_name ON sql_id USING HINT hint;

参数说明：

• sql_id：需要绑定的 SQL 对应的 SQL_ID，可通过查询 GV$OB_PLAN_CACHE_PLAN_STAT 或 GV$OB_SQL_AUDIT 表获取，也可通过 MD5 生成。
• hint：格式为 /*+ xxx */，用于指定优化器行为。
• 如果 sql_id 对应的 SQL 语句已有 Hint，则创建 Outline 指定的 Hint 会覆盖原始语句中所有 Hint。

-- 示例：使用 SQL_ID 创建 Outline
        CREATE OUTLINE otl_idx_c2 ON 'ED570339F2C856BA96008A29EDF04C74' USING HINT /*+ index(t1 idx_c2)*/ ;

上述示例来源：CREATE OUTLINE-V4.5.0。

Outline 的优先级与覆盖规则

当同一个 SQL 同时满足多种 Outline 绑定方式时，遵循以下优先级规则：

• 优先级高低：当 SQL_ID 相同时，使用 SQL_TEXT 方式创建的 Outline 会覆盖 SQL_ID 方式创建的 Outline，SQL_TEXT 方式创建的优先级更高。
• Outline vs SPM：Outline（通过 CREATE OUTLINE 显式绑定）优先级最高，其次是 SPM 基线中的已接受计划，最后才是优化器自动生成的非基线计划。Outline 主要用于关键业务的计划锁定，SPM 则用于自动管理计划基线。当两者同时存在时，Outline 明确指定的计划具有最高优先级，系统不会考虑 SPM 中的其他计划。

验证 Outline 是否生效

创建 Outline 后，需要通过以下步骤确认 Outline 是否生效：

1. 确认 Outline 创建成功：通过查看 GV$OUTLINE 表，确认是否成功创建了对应名称的 Outline。

   -- 查询 Outline 是否创建成功
           SELECT * FROM oceanbase.GV$OUTLINE WHERE outline_name = 'otl_idx_c2'\G;

2. 确认 SQL 执行使用了绑定计划：当绑定了 Outline 的 SQL 有新的流量执行后，查询 GV$OB_PLAN_CACHE_PLAN_STAT 表中该 SQL 对应的计划信息，确认 OUTLINE_ID 字段是否为绑定的 Outline ID。

   -- 查看 SQL 实际使用的执行计划及 Outline 信息
           SELECT SQL_ID, PLAN_ID, OUTLINE_ID, OUTLINE_DATA 
           FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT 
           WHERE SQL_ID = 'ED570339F2C856BA96008A29EDF04C74';

管理 Outline

✏️ 修改 Outline

OceanBase 支持通过 ALTER OUTLINE 语句修改 Outline，仅支持修改使用 SQL_TEXT 创建的 Outline。语法如下：

ALTER OUTLINE outline_name ADD stmt [ TO target_stmt ];

🗑️ 删除 Outline

删除 Outline 后，对应 SQL 重新生成计划时将不再依据绑定的 Outline 生成。删除 Outline 需要在 outline_name 中指定数据库名称，或者先执行 USE database_name 后再删除。

-- 删除 Outline（需在对应数据库下执行，或指定完整名称）
        DROP OUTLINE otl_idx_c2;

        -- 指定数据库名称删除
        DROP OUTLINE test.otl_idx_c2;

Outline 监控视图

OceanBase 提供了完整的 Outline 监控视图体系，从 V4.0.0 版本开始引入，帮助 DBA 查看和管理 Outline 信息。

📊 核心视图说明

📋 查询示例

-- 查看当前租户的执行计划 Outline 信息
        SELECT OUTLINE_NAME, SQL_TEXT, OUTLINE_TARGET, SQL_ID, OUTLINE_CONTENT
        FROM oceanbase.DBA_OB_OUTLINES;

        -- 查看 Outline 历史信息（用于排查变更记录）
        SELECT * FROM oceanbase.DBA_OB_OUTLINE_CONCURRENT_HISTORY\G;

Hint、Outline 与 SPM 的定位对比

在 OceanBase 中，Hint、Outline 和 SPM 虽然都用于管理执行计划，但它们的定位和使用场景有明显区别。了解三者的区别有助于在合适场景选择正确的计划管理手段。

Sysbench 是一个基于 LuaJIT 的可编写脚本的多线程基准测试工具，可以执行 CPU、内存、线程、IO 和数据库等方面的性能测试，常用于评估测试各种不同系统参数下的数据库负载情况，不需要修改源码，通过自定义 lua 脚本就可以实现不同业务类型的测试。通过 Sysbench 压测，可以验证 OceanBase 在 OLTP 场景下的性能上限、定位系统瓶颈，并为生产环境的容量规划提供数据支撑。

测试前准备

在开始 Sysbench 压测之前，建议完成以下准备工作，以确保测试结果的准确性和可复现性。

软硬件环境

租户参数调优

创建专门用于压测的业务租户，并完成以下基础参数配置，以发挥最佳性能：

• 资源单元：根据测试目标创建合适的 RESOURCE UNIT，确保分配足够的 CPU 和内存资源，建议参考官方性能测试报告中的规格配置。
• PRIMARY_ZONE：建议设置为 RANDOM，使新建表分区的 Leader 均匀分布在 Zone 之间，避免单节点成为瓶颈。
• 租户规格查看：压测前可通过 SHOW CREATE TENANT xxx; 和 DBA_OB_UNITS 等视图确认租户的 CPU 和内存分配是否符合预期。

-- 创建压测专用资源单元和租户的示例（硬性规格需根据实际硬件调整）
        CREATE RESOURCE UNIT sysbench_unit MAX_CPU 26, MIN_CPU 26, MEMORY_SIZE '100G';
        CREATE RESOURCE POOL sysbench_pool UNIT='sysbench_unit', UNIT_NUM=1, ZONE_LIST=('zone1','zone2','zone3');
        CREATE TENANT sysbench_tenant resource_pool_list=('sysbench_pool'), PRIMARY_ZONE='RANDOM',
        LOCALITY='F@zone1,F@zone2,F@zone3' SET ob_compatibility_mode='mysql', ob_tcp_invited_nodes='%';

数据库参数调优

下表基于 Sysbench 压测场景总结了部分关键参数的最佳实践：

注意：压测场景通常以追求极致性能为目标，与生产环境侧重稳定性的调优方向可能不同。生产环境下应谨慎调整限流和合并相关参数。

OBClient 与 ODP 调优

• 当 OBClient 版本 ≥ 2.2.0 时，会默认开启 ob20 协议及全链路追踪能力，在 Sysbench 测试中会影响性能，建议通过设置环境变量手动关闭：export ENABLE_PROTOCOL_OB20=0。
• ODP 的高并发处理能力需提前验证，建议预先测试 ODP 在目标并发下的 CPU 消耗，避免代理层成为瓶颈。
• 应用侧应启用连接池复用，并限制单实例最大连接数，防止在高并发下因频繁建连/断连消耗 ODP 资源。

执行压测

OceanBase 支持两种方式进行 Sysbench 测试，可根据实际需求灵活选择。

方式一：OBD test 命令一键压测（推荐）

OBD（OceanBase Deployer）提供了 test 命令，可一键完成 Sysbench 测试，是最快捷的方式。

# 运行 Sysbench 测试（示例）
        obd test sysbench obcluster --tenant=sysbench_tenant --user=root@sysbench_tenant \
        --password=123456 --script=point_select --tables=30 --table-size=1000000 \
        --threads=32 --time=60

OBD test 命令中 --tenant 参数只能指定一个租户名，--user 仅需指定用户名，无需重复指定数据库名。

方式二：基于官方 Sysbench 工具手动逐步测试

这种方式提供了更高的灵活性，支持自定义测试场景和参数组合。

# 1. 准备测试数据（prepare）
        sysbench /usr/local/share/sysbench/oltp_read_write.lua \
        --mysql-host=127.0.0.1 --mysql-port=2883 \
        --mysql-user=root@sysbench_tenant --mysql-password=123456 \
        --mysql-db=test --tables=30 --table-size=1000000 \
        --threads=32 --db-ps-mode=disable --rand-type=uniform prepare

        # 2. 执行压测（run）
        sysbench /usr/local/share/sysbench/oltp_read_write.lua \
        --mysql-host=127.0.0.1 --mysql-port=2883 \
        --mysql-user=root@sysbench_tenant --mysql-password=123456 \
        --mysql-db=test --tables=30 --table-size=1000000 \
        --threads=32 --time=60 --report-interval=10 \
        --db-ps-mode=disable --rand-type=uniform run

        # 3. 清理测试数据（cleanup）
        sysbench /usr/local/share/sysbench/oltp_read_write.lua \
        --mysql-host=127.0.0.1 --mysql-port=2883 \
        --mysql-user=root@sysbench_tenant --mysql-password=123456 \
        --mysql-db=test cleanup

参数说明：--db-ps-mode=disable 可关闭 prepare statement，避免在测试中产生额外的 prepare 开销；--rand-type=uniform 建议设置为 uniform，以减少数据间的锁竞争，避免因随机分布导致的热点问题。

压测结果分析

完成压测后，应关注以下核心性能指标，并与预期目标进行对比。

性能基线参考（V4.2.2，3 节点 1-1-1 规格）

以下为官方 Sysbench 性能测试报告中的部分结果，可作为基准参考（实际性能取决于硬件配置）：

数据来源：OceanBase 官方性能测试报告。

关键指标解读

• QPS / TPS：吞吐量指标。若随并发增加不再线性增长，说明系统可能已达到处理瓶颈。
• 延迟（Latency）：重点关注 P95 和 P99 延迟。如果延迟突然陡升，可能由锁等待、内存不足或后台任务（合并/转储）干扰导致。
• CPU 使用率：通过 top -H -p pidof observer 观察各业务线程（如 T1002_L0_G2）的 CPU 占用情况，判断瓶颈类型。
• 成功率/错误数：若出现大量错误，需检查是否存在主键冲突、死锁或超时等异常情况。

问题排查与优化

Sysbench 的 TPS 低于预期

当压测结果达不到预期时，可以按照以下步骤进行系统化的排查：

1. 分析 Sysbench 参数：检查 --rand-type 是否为 uniform，--db-ps-mode 是否已 disable。表数量和大小过小时可适当调大（如 tables=100, table_size=1,000,000）。
2. 确认连接方式：PRIMARY_ZONE = RANDOM 时必须连接 ODP 进行测试；若 Primary Zone 为单 Zone 且直连 OBServer，需确认连接的是 Leader 节点，否则读请求可能被转发到 Follower。
3. 观察 CPU 开销：top -H -p pidof observer
   • 若业务线程基本打满一个 CPU 核且线程数量接近 CPU 总核数 → 机器性能已达极限，需使用更高配置的服务器。
   • 若业务线程数量远低于 CPU 核数且 CPU 总开销远未达上限 → cpu_count 可能分配过少，需检查租户创建命令。
   • 若业务线程 CPU 占用仅为 20%~50% → 其他地方（网络/磁盘/锁）存在瓶颈。
4. 分析硬件原因：排除 CPU 因素后，排查磁盘和网络瓶颈——确认网卡带宽上限（ethtool），用 ping 测试网络延迟，或用 FIO 测试日志盘的 16K 写入带宽。
5. 检查后台任务干扰：查看压测期间是否触发了转储/合并（可通过 GV$OB_COMPACTION_PROGRESS 或 OCP 监控确认），导致 CPU 飙升并拉低 TPS。转储合并的影响程度与租户规格相关，4C8G 租户下 TPS 可能下降 80%，而 32C64G 租户下降幅度可控制在 10% 左右。

常见报错与解决

• ERROR 6002（死锁相关）：可能因并发写入同一行导致。建议调大数据集、增加 tables 数量（如 tables=100），或将 --rand-type 设为 uniform 减少锁冲突，也可在 Sysbench 命令中添加 --mysql-ignore-errors=1062,1213,6002 忽略部分可预期错误。
• 主键冲突（Duplicate entry）：通常由 Sysbench 生成的随机数据碰撞导致。可增加 tables 数量降低碰撞概率，或使用新版 OBD test 命令进行压测以避免部分问题。
• ERROR 4012（超时）：检查压测租户的 ob_query_timeout、ob_trx_timeout 是否设置过小，或是压测 SQL 执行效率低下触发超时。
• 网络线程（RpcIO）打满 CPU：可能因网络通信成为瓶颈，可尝试增加 net_thread_count（修改后需重启 OBServer）。

结果验证与后续优化

• 稳定性验证：建议执行 4 小时以上的长稳压测（--time=14400），重点关注长时间运行下是否出现性能衰减、内存泄漏或服务不稳定。
• 反哺生产配置：将压测中验证有效的最佳实践参数同步到生产环境配置模板中，并在重大版本升级后重新执行压测，验证性能是否符合预期。
• 若 QPS 波动呈现规律性下降，可通过查询视图 GV$OB_COMPACTION_PROGRESS 判断是否为转储合并操作导致，转储合并会占 CPU 资源，导致业务线程受影响。

在 OceanBase 数据库中，优化器通常会选择最优的执行计划。然而，由于统计信息的滞后、数据分布的变化或系统版本的升级，SQL 的执行计划有时会发生意料之外的“跳变”（plan regression），从高效计划退化为低效计划，严重影响业务性能。SQL 计划管理（SQL Plan Management，以下简称 SPM）正是为此而设计的一套自动化计划治理机制。它通过建立和演进 “SQL 计划基线”，确保只有经过实际验证的新计划才能被使用，从而有效防止计划回退。

核心工作原理

SPM 基于 SQL Plan Baseline 实现。每个 Plan Baseline 持久化存储一个已经验证过的执行计划信息（即 `outline_data`），通过这些信息可以精确复现该计划。

SPM 的工作流程遵循“先捕获，再演进”的自动化循环：

1. 计划捕获：当系统为某个 SQL 生成新计划时，如果 SPM 中被开启（`optimizer_use_sql_plan_baselines=true`），新计划将自动被捕获并加入演进队列；否则仅做基线匹配。
2. 计划演进：当新计划与基线计划不同时，系统会自动启动一个演进任务，利用随后的真实业务流量进行“金丝雀（Canary）测试”，持续监控新计划的性能表现。这包括执行时间、物理/逻辑读、并发度等实际指标。
3. 计划选择：在演进完成后，如果验证发现新计划性能优于基线，则自动将新计划标记为 `ACCEPTED` 并替代原有基线；如果性能不及预期，则忽略该计划，后续执行继续使用基线。

值得注意的是，对于一条没有基线计划的 SQL，其第一次执行成功的计划会被系统默认标记为 `ACCEPTED` 状态，成为该 SQL 的初始计划基线。因此，在 SQL 上线前确保其使用了最优的执行计划至关重要。

开启与关闭 SPM

SPM 通过两个核心租户级系统变量来控制其行为，正确的组合设置非常重要。下表列出了所有组合下系统的实际行为：

-- 1. 查看当前 SPM 状态（建议在业务租户下执行）
        SHOW VARIABLES LIKE 'optimizer_use_sql_plan_baselines';
        SHOW VARIABLES LIKE 'optimizer_capture_sql_plan_baselines';

        -- 2. 完整开启 SPM 功能（生产环境推荐配置）
        SET GLOBAL optimizer_capture_sql_plan_baselines = 'true';
        SET GLOBAL optimizer_use_sql_plan_baselines = 'true';

        -- 3. 完全关闭 SPM 功能（V4.x 版本请谨慎使用，关闭后基线不生效）
        SET GLOBAL optimizer_use_sql_plan_baselines = 'false';
        SET GLOBAL optimizer_capture_sql_plan_baselines = 'false';

        -- 4. 查看当前租户的 SPM 配置参数（可通过视图查询）
        SELECT * FROM oceanbase.DBA_SQL_MANAGEMENT_CONFIG;

手动干预与演进验证

虽然 SPM 设计上主张自动化，但在某些需要人为确认或批量导入的场景下，OceanBase 提供了 DBMS_SPM 系统包进行精细控制：

• DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE：从计划缓存中批量加载 SQL 计划，构建基线。
• DBMS_SPM.ACCEPT_SQL_PLAN_BASELINE：手动接受某个演进中的计划，将其状态从 `REJECTED` 或演进队列中改为 `ACCEPTED`，从而使该计划成为新的基线。
• DBMS_SPM.DROP_SQL_PLAN_BASELINE：从基线中删除指定的计划，返回值为 `PLS_INTEGER`，表示删除的计划数量。

-- 使用 DBMS_SPM 手动接受一个演进计划
        DECLARE
            v_accept_plans NUMBER;
        BEGIN
            v_accept_plans := DBMS_SPM.ACCEPT_SQL_PLAN_BASELINE(
                sql_handle  => '529F6E6454EF579C7CC265D1F6131D70',
                plan_name   => '3388268709115914355'
            );
            DBMS_OUTPUT.PUT_LINE('Number of accepted plans: ' || v_accept_plans);
        END;
        /

SPM 核心状态枚举与基线选择逻辑

通过 `DBA_SQL_PLAN_BASELINES` 视图，可以详细查看每个 Plan Baseline 的状态，不同状态决定了计划的最终选择和演进行为：

• ENABLED = 'YES' / `'NO'`：计划是否启用，只有 `YES` 时才会被纳入基线管理和选择考虑。
• ACCEPTED = 'YES' / `'NO'`：计划是否被验证通过，`YES` 表示该计划已被验证为优，`NO` 表示计划尚在演进中或未被确认。
• FIXED = 'YES' / `'NO'`：计划是否被用户“锁定”。当基线中的某个计划被标记为 `FIXED` 后，它将拥有最高优先级，系统将无条件优先使用该计划，并且不会触发任何演进任务，直到该计划被解除锁定。

此外，部分失效的 Plan Baseline 会被系统自动设置为 `REPRODUCED = 'NO'`，表示因依赖对象（如下线索引）的删除而无法成功复现执行计划。

-- 查看当前租户的计划基线详情
        SELECT SQL_HANDLE, PLAN_NAME, ENABLED, ACCEPTED, FIXED, REPRODUCED 
        FROM oceanbase.DBA_SQL_PLAN_BASELINES
        WHERE SIGNATURE = 'your_sql_signature';

        -- 查看基线中所有计划的信息
        SELECT * FROM oceanbase.DBA_SQL_PLAN_BASELINES\G

SPM 的使用限制

在 OceanBase 4.x 版本中，SPM 功能存在以下使用限制，设计和验证时需注意：

• 恢复中的租户（under recovery）和主备部署中的备租户（standby cluster），无法执行计划演进。
• `sys` 租户相关的 SQL 语句，以及数据库内部的 SQL 语句，均不参与计划演进。
• 包含 `INSERT INTO VALUES` 子句的 SQL 语句，不参与计划演进。

监控 SPM 运行状态

OceanBase 提供了系统视图用于监控 SPM 的运行状态和配置，从 V4.0.0 版本开始引入：

• oceanbase.DBA_SQL_PLAN_BASELINES：展示当前租户中所有的 SQL 计划基线。包含该计划基线的创建方式（`ORIGIN` 值：`AUTO-CAPTURE` 自动捕获，`MANUAL-LOAD` 手动加载等）、创建者、启用/采纳/固定状态等信息。
• oceanbase.DBA_SQL_MANAGEMENT_CONFIG：展示当前租户的 SPM 配置参数，如基线自动保留策略、演进任务开关、演进间隔等。其中 PLAN_RETENTION_WEEKS 控制 Plan Baseline 的保留周期，SPACE_BUDGET_PERCENT 控制可用内存占比，AUTO_SPM_EVOLVE_TASK 表示自动演进开关。

-- 查看当前租户的所有计划基线信息
        SELECT * FROM oceanbase.DBA_SQL_PLAN_BASELINES\G

        -- 查看当前租户的 SPM 相关配置（基线保留策略等）
        SELECT PARAMETER_NAME, PARAMETER_VALUE FROM oceanbase.DBA_SQL_MANAGEMENT_CONFIG;

        -- 调整 Plan Baseline 的保留周期（默认为 53 周）
        UPDATE oceanbase.DBA_SQL_MANAGEMENT_CONFIG 
        SET PARAMETER_VALUE = 52 WHERE PARAMETER_NAME = 'PLAN_RETENTION_WEEKS';

        -- 关闭自动演进功能
        UPDATE oceanbase.DBA_SQL_MANAGEMENT_CONFIG 
        SET PARAMETER_VALUE = 'OFF' WHERE PARAMETER_NAME = 'AUTO_SPM_EVOLVE_TASK';

OceanBase 数据库是一个原生支持多租户架构的分布式数据库系统。为了确保不同租户间的业务稳定运行、避免资源争抢，OceanBase 在数据库内部实现了完善的租户间资源隔离机制，对 CPU、内存、IOPS 等关键资源进行精细化管理。

资源隔离的基本单位：Unit

在 OceanBase 数据库中，资源单元（Unit）是给租户分配资源的基本单位。一个 Unit 可以类比于一个 Docker 容器，它定义了 CPU、内存、日志磁盘空间和 IOPS 等资源的规格。Unit 具有节点、Zone、Region 等位置属性，节点是服务器的抽象，Zone 是机房的抽象，Region 则是地域的抽象。

Unit 的关键特性：

• 一个节点上可以创建多个 Unit，每创建一个 Unit 都会占用一部分该节点的物理资源。
• 一个租户可以在多个节点上放置多个 Unit，但一个租户在某个节点上只能有一个 Unit。
• 租户的多个 Unit 相互独立，资源隔离是节点本地的行为——如果一个租户在某个节点上的资源未得到满足，它不会在另一个节点上抢占其他租户的资源。
• 资源单元是资源调度的基本单位，节点的资源分配情况会记录在内部表中以便 DBA 查看。

Unit 的创建与管理

-- 创建资源单元配置（Unit Config）
        CREATE RESOURCE UNIT unit1 
            MAX_CPU=8, MIN_CPU=4, 
            MEMORY_SIZE='32G', 
            MAX_IOPS=128000, MIN_IOPS=128000, 
            LOG_DISK_SIZE='2T';

        -- 查看集群中所有 Unit 配置
        SELECT * FROM oceanbase.DBA_OB_UNIT_CONFIGS;

        -- 查看当前集群中各个节点上的 Unit 分布
        SELECT TENANT_ID, UNIT_ID, SVR_IP, SVR_PORT, MAX_CPU, MEMORY_SIZE
        FROM oceanbase.GV$OB_UNITS;

OceanBase 数据库并没有依赖 Docker 或虚拟机技术来实现资源隔离，而是在数据库内核中直接实现，相比 Docker 和虚拟机更加轻量，并且便于实现优先级等高级特性。

租户内存隔离

OceanBase 实现了内存完全隔离，内存被视为“刚性资源”，分配后无法被其他租户使用，必须显式释放。一个租户的内存耗尽可能导致该租户的写入操作受阻，但不会影响到其他租户的正常运行。

租户内存的组成结构

每个租户的内存由用户租户本身及其对应的 Meta 租户的内存共同组成，可划分为两大类别：

• 不可动态伸缩内存（Non-auto-scaling Memory）：主要包括 MemStore（存储增量数据）和 SQL Work Area（SQL 排序等阻塞算子使用的工作区内存）。
• 可动态伸缩内存（Auto-scaling Memory / KVCache）：由 KVCache 统一管理，包括 Row Cache（数据行缓存）、Block Cache（数据块缓存）、Schema Cache（表结构元数据缓存）等。KVCache 会尽量使用除去不可动态伸缩内存后的全部租户内存，当租户内存紧张时，会优先从中淘汰未被引用的内存。

核心内存配置参数

租户 CPU 隔离

OceanBase 从 V4.0.0 版本开始支持租户间 CPU、内存、IOPS 隔离，一个 Unit 可以指定 CPU、内存、IOPS、日志磁盘空间四种资源。一个租户能使用的 CPU 资源由 Unit 规格决定。CPU 被视为弹性资源，可通过调度算法在不同租户间动态分配。

基于线程数的软隔离（基础方案）

这是 OceanBase 最基础的 CPU 隔离机制，通过控制每个租户的活跃工作线程数量来实现 CPU 资源限制。核心原理是：每个租户有独立的线程池，线程池大小由 Unit 规格中的 MAX_CPU 和 MIN_CPU 决定，通过控制并发执行的线程数间接限制 CPU 使用。

OBServer 采用以下公式计算租户的工作线程数：

-- 活跃工作线程数 = cpu_count * cpu_quota_concurrency（默认为 4）
        -- 线程总数上限 = cpu_count * workers_per_cpu_quota

重要说明：cpu_quota_concurrency 默认为 4，表示每个物理 CPU 核对应 4 个工作线程。这种设计是因为 SQL 执行过程中可能存在 IO 等待、锁等待等情况，单个线程无法完全利用一个 CPU 核心。

-- 创建资源单元时指定 CPU 规格
        CREATE RESOURCE UNIT web_unit 
            MAX_CPU=8,   -- 最大可使用的 CPU 核数，决定线程池上限
            MIN_CPU=4,   -- 保障的最低 CPU 核数（开启超卖时有效）
            MEMORY_SIZE='16G', 
            LOG_DISK_SIZE='20G';

基于 cgroup 的硬隔离（增强方案）

为了达到更好的隔离效果，从 V4.0.0 版本开始，OceanBase 支持配置 cgroup（Control Groups）来实现更精确的 CPU 隔离。cgroup 是 Linux 内核提供的机制，能够对线程的 CPU 使用率进行精准限制，达到租户间 CPU 强隔离的效果。

cgroup 的使用限制与注意事项：

• 要求 Linux 内核版本必须为 Linux Kernel 4.19 及以上版本。
• 以下场景下不建议使用 cgroup：单租户场景、租户之间有业务关联的场景（如上下游微服务）、小规格租户场景（CPU 为 2C 或 4C）。
• OceanBase 数据库升级后，需要重新配置 cgroup。
• 如果 OBServer 服务器重启，创建好的 cgroup 子目录会被清除，需要重新配置 cgroup。
• 配置 User 级资源隔离和 Function 级资源隔离时，如果不需要控制 CPU 的资源隔离，则不需要配置 cgroup；配置 SQL 级资源隔离时，无论是否需要控制 CPU 的资源隔离，均需要配置 cgroup。

租户 IOPS 隔离

OceanBase 从 V4.0.0 版本开始支持租户间 IOPS 隔离，通过 Unit 规格中的 MAX_IOPS 和 MIN_IOPS 参数来限制租户的磁盘读写次数，并支持通过权重（IOPS_WEIGHT）进行资源分配。IOPS 被视为弹性资源，可根据权重动态调整带宽分配。

IOPS 隔离的关键配置

• Unit Config 中的 MAX_IOPS（最小值 1024）和 MIN_IOPS 参数控制租户 IOPS 配额。
• IOPS 配置前建议进行磁盘性能校准，确保 MAX_IOPS 和 MIN_IOPS 不高于以 16KB 随机读测试得出的基线 IOPS 值。
• 配置 SQL 级资源隔离时，无论是否需要控制 CPU 的资源隔离，均需要配置 cgroup。

-- 在 Unit Config 中配置 IOPS 参数
        CREATE RESOURCE UNIT io_unit 
            MAX_CPU=8, MIN_CPU=4,
            MEMORY_SIZE='32G',
            MAX_IOPS=128000, MIN_IOPS=128000,   -- IOPS 配置
            LOG_DISK_SIZE='2T';

        -- 查看当前租户的 IOPS 使用情况
        SELECT TENANT_ID, NAME, MAX_IOPS, MIN_IOPS, IOPS_WEIGHT 
        FROM oceanbase.DBA_OB_UNIT_CONFIGS;

多租户资源隔离的隔离效果

从普通租户用户的角度，可以看到以下隔离效果：

• 内存完全隔离：SQL 执行过程中各种算子使用的内存分离，Block Cache 和 MemStore 分离，一个租户的内存耗尽不会影响到另一个租户的写入和读取。
• SQL 模块隔离：不同租户的 Plan Cache 和 Audit 表完全分离，互不影响。
• 事务模块隔离：一个租户的行锁挂起、事务挂起、日志回放异常等均不会影响其他租户。
• 日志模块隔离：日志流的目录以租户为单位组织：tenant_id/unit_id_*/log 等目录结构独立存放。

租户内资源隔离：三种粒度

除了租户间资源隔离，OceanBase 还通过 DBMS_RESOURCE_MANAGER 系统包支持租户内资源隔离，分为三种粒度：

1️⃣ 用户级资源隔离

指定用户与资源组的映射关系，使该用户执行的所有 SQL 使用的资源即为对应资源组分配的资源。通过该特性，可以让不同用户执行不同类型的任务，实现资源隔离。

2️⃣ 后台任务级资源隔离

指定后台任务与资源组的映射关系，隔离各任务使用的资源。当前支持 8 种后台任务：

• compaction_high：Mini Merge 和 DDL KV Merge 任务
• ha_high：复制、Rebuild 和恢复等高优先级高可靠任务
• compaction_mid：Minor Merge 任务
• ha_mid：迁移等中优先级高可靠任务
• compaction_low：Major Merge 任务
• ha_low：备份和备份清理等低优先级高可靠任务
• ddl：唯一索引校验、删列补数据等场景的任务
• ddl_high：DDL MemTable 的转储任务

3️⃣ SQL 级资源隔离

通过将满足某个条件的 SQL 绑定到指定资源组上执行来实现资源隔离。通常适用于业务中存在大账号和小账号的场景——将处理不同订单的 SQL 绑定到不同的资源组，避免大账号把 CPU 资源用完导致小账号的订单无法得到处理。

OceanBase 数据库支持对前台 SQL 和后台任务进行资源隔离，以保证关键业务的稳定运行。通过资源组（Resource Group）和资源管理计划（Resource Plan），可以灵活限制不同后台任务对 CPU、IOPS 等资源的占用，避免后台任务（如转储、合并、备份等）占用过多系统资源而影响正常的业务请求。

资源隔离的基本概念

OceanBase 数据库通过 DBMS_RESOURCE_MANAGER 系统包来管理数据库中资源的分配，从而实现资源隔离。其中涉及三个核心组件：

• 资源组（Resource Consumer Group）：根据资源要求组合在一起的一组会话。系统将资源分配给资源组，而不是单个会话。前台 SQL 可以按用户、SQL 条件绑定到不同资源组，后台任务也通过预定义的 FUNCTION 映射到资源组。
• 资源管理计划（Resource Plan）：资源管理计划内容的容器，指定如何将资源分配给资源组。您可以通过激活特定的资源管理计划来控制资源的分配。
• 资源管理计划内容（Resource Plan Directive）：用于将资源组与资源管理计划相关联，并指定如何将资源分配给该资源组。一条资源管理计划可以对应多条资源管理计划内容，但一条资源管理计划中不能包含两条相同的资源管理计划内容。

后台任务资源隔离（Function 级资源隔离）

Function 级的资源隔离是通过指定后台任务与资源组的映射关系，隔离各任务使用的资源。由于 OceanBase 数据库后台执行的诸如合并转储、备份恢复和数据补全等任务，不在 User 范畴之内，且执行时可能挤占前台用户任务的 CPU 和 IO 资源。因此，针对不同后台任务可以指定 FUNCTION 映射关系，后台任务的资源可以被限制在其对应的资源组内。

支持的后台任务类型

OceanBase 数据库支持将不同类型后台任务映射到资源组，当前支持以下 8 种类型：

简化配置：官方推荐的分组策略

由于自由配置后台任务的资源隔离方法较为复杂，OceanBase 官方将资源请求类型分为三组，推荐使用以下分组策略进行配置。

资源分组详情

官方推荐资源隔离策略

根据分组情况，OceanBase 推荐以下资源隔离配置。

配置后台任务资源隔离的完整步骤

前置条件

• 如果需要控制 CPU 的资源隔离，在配置后台任务资源隔离前，必须配置 cgroup 目录并开启 cgroup 功能。配置 cgroup 目录并开启 cgroup 功能的相关操作，参见官方文档 配置 cgroup。
• 仅进行 IOPS 资源隔离（不控制 CPU）时，不需要配置 cgroup。
• 当前版本中，CPU 和 IOPS 资源隔离均不再强制依赖磁盘性能校准操作，可根据需要选择是否执行。

步骤一：创建资源组

-- 创建前台任务资源组和后台任务资源组
        -- 使用 root 用户登录 sys 租户

        -- 创建前台业务资源组（默认定于高优先级用户 SQL）
        CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
            CONSUMER_GROUP => 'online_group',
            COMMENT => '前台业务资源组'
        );

        -- 创建后台任务资源组（低优先级）
        CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
            CONSUMER_GROUP => 'background_group',
            COMMENT => '后台任务资源组'
        );

步骤二：创建资源管理计划

-- 创建资源管理计划
        CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN(
            PLAN => 'resource_plan',
            COMMENT => '资源管理计划（前台+后台隔离）'
        );

步骤三：配置资源计划指令（为资源组分配资源）

-- 配置资源计划指令，为资源组分配 CPU 和 IOPS 资源
        -- 前台业务资源组：高优先级，分配更多的 CPU 资源
        CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
            PLAN => 'resource_plan',
            GROUP_OR_SUBPLAN => 'online_group',
            COMMENT => '前台业务资源组：高优先级',
            MGMT_P1 => 80,  -- CPU 总资源分配80（权重方式）
            MIN_IOPS => 50,
            MAX_IOPS => 100,
            WEIGHT_IOPS => 80,
            CPU_WEIGHT => 80   -- CPU 资源分配权重
        );

        -- 后台任务资源组：低优先级，分配较少的 CPU 资源
        CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
            PLAN => 'resource_plan',
            GROUP_OR_SUBPLAN => 'background_group',
            COMMENT => '后台任务资源组：低优先级',
            MGMT_P1 => 20,
            MIN_IOPS => 10,
            MAX_IOPS => 100,
            WEIGHT_IOPS => 20,
            CPU_WEIGHT => 20   -- CPU 资源分配权重
        );

步骤四：建立后台任务与资源组的映射关系

-- 将不同后台任务 FUNCTION 映射到指定资源组
        CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
            ATTRIBUTE => 'FUNCTION',
            VALUE => 'COMPACTION_HIGH',
            CONSUMER_GROUP => 'background_group'
        );

        CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
            ATTRIBUTE => 'FUNCTION',
            VALUE => 'COMPACTION_LOW',
            CONSUMER_GROUP => 'background_group'
        );

        CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
            ATTRIBUTE => 'FUNCTION',
            VALUE => 'HA_LOW',
            CONSUMER_GROUP => 'background_group'
        );

        CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
            ATTRIBUTE => 'FUNCTION',
            VALUE => 'HA_MID',
            CONSUMER_GROUP => 'background_group'
        );

        CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
            ATTRIBUTE => 'FUNCTION',
            VALUE => 'DDL',
            CONSUMER_GROUP => 'background_group'
        );

        CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
            ATTRIBUTE => 'FUNCTION',
            VALUE => 'CLOG_HIGH',
            CONSUMER_GROUP => 'background_group'
        );

上述是构建后台任务资源隔离的核心环节。针对不同的后台任务 FUNCTION，可以通过 SET_CONSUMER_GROUP_MAPPING 过程进行精细化管理。

步骤五：激活资源管理计划

-- 设置 resource_manager_plan 激活资源管理计划
        -- 必须在业务租户下执行
        ALTER SYSTEM SET resource_manager_plan = 'resource_plan';

        -- 验证资源管理计划已激活
        SHOW PARAMETERS LIKE 'resource_manager_plan';

        -- 停用资源管理计划
        ALTER SYSTEM SET resource_manager_plan = '';

可选：磁盘性能校准（如需要 IOPS 精准隔离）

如果需要精确配置 IOPS 隔离，可执行以下磁盘校准操作（注意：当前版本中，CPU 和 IOPS 资源隔离均不再强制依赖磁盘性能校准，可根据需要选择是否执行）。

-- 在 sys 租户中执行磁盘校准
        ALTER SYSTEM RUN JOB "io_calibration";

        -- 查看校准进度
        SELECT * FROM oceanbase.GV$OB_IO_CALIBRATION_STATUS;

        -- 查看校准值（校准完成后执行）
        SELECT * FROM oceanbase.GV$OB_IO_BENCHMARK;

监控资源隔离状态

OceanBase 数据库提供了多个视图用于监控资源隔离的配置和运行状态。

资源组监控视图

-- 查看当前租户的所有资源组
        SELECT RESOURCE_GROUP_ID, RESOURCE_GROUP_NAME, COMMENT 
        FROM oceanbase.DBA_OB_RSRC_GROUPS;

        -- 查看资源管理计划内容（资源配置详情）
        SELECT PLAN, GROUP_OR_SUBPLAN, MGMT_P1, MIN_IOPS, MAX_IOPS, WEIGHT_IOPS, CPU_WEIGHT 
        FROM oceanbase.DBA_OB_RSRC_DIRECTIVES;

        -- 查看资源管理计划状态（是否激活）
        SELECT PLAN_NAME, STATUS FROM oceanbase.DBA_OB_RSRC_PLANS;

        -- 查看后台任务与资源组的映射关系
        -- 可通过 DBA_OB_RSRC_MAPPING 视图查看
        SELECT ATTRIBUTE, VALUE, CONSUMER_GROUP 
        FROM oceanbase.DBA_OB_RSRC_MAPPING 
        WHERE ATTRIBUTE = 'FUNCTION';

资源管理计划的优先级与校验规则

当激活某个资源管理计划后，该计划中的所有资源组会按照以下规则获得资源：

• 在系统满负载时，资源组按照 MGMT_P1 参数按比例分配 CPU 资源（总和不超过 100）。MGMT_P1 指定系统满负载情况下，相对可用的最大 CPU 占比。
• 在系统未达满负载时，资源组可无限制使用 CPU，MGMT_P1 仅作为满负载下的保障比例。
• IOPS 资源按照 MIN_IOPS、MAX_IOPS、WEIGHT_IOPS 联合控制。
• 一个资源管理计划中不能包含两条相同的资源管理计划内容（即同一个资源组在同一个计划中只能出现一次）。

在 OceanBase 4.x 架构中，集群管理、租户管理、资源调度等核心职责均由 RootService 承担。而 RootService 本身运行于系统租户（sys tenant）之上，集群早期的元数据膨胀和调度瓶颈问题对集群稳定性构成挑战。为此，OceanBase V4.0 引入了 Meta 租户，将每个用户租户的私有元数据（如配置项、位置信息、副本信息、日志流状态、备份恢复信息、合并信息等）迁移至专属的 Meta 租户管理，实现了更细粒度的资源隔离，减轻了系统租户的负担。

Meta 租户详解

定位与数据属性

Meta 租户用于存储和管理用户租户的集群私有数据，这部分数据不需要进行跨库物理同步以及物理备份恢复，例如：配置项、位置信息、副本信息、日志流状态、备份恢复相关信息、合并信息等。Meta 租户的数据存储格式与用户租户一致，但不可直接登录访问，普通用户只能通过系统租户的视图来查询 Meta 租户下的数据。

ID 规则与命名规范

Meta 租户与用户租户采用固定的 ID 编码映射关系：

• 用户租户 ID：最小值 1002，最低位编码为 0（偶数）。
• Meta 租户 ID：最小值 1001，最低位编码为 1（奇数），且 Meta 租户 ID + 1 = 用户租户 ID。
• 命名规范：Meta 租户的默认名称为 META${user_tenant_id}。例如，用户租户 ID 为 1002 时，其对应 Meta 租户名为 META$1002。

资源分配与运维限制

Meta 租户没有独立的 Unit，创建租户时系统默认为 Meta 租户预留资源，各项资源从用户租户的资源中扣除。资源分配规则如下：

Meta 租户的运维操作存在明确限制：

• 不支持创建、删除、重命名 Meta 租户（生命周期与用户租户自动绑定）。
• 不支持用户登录访问 Meta 租户。
• 不支持修改 Meta 租户的 Locality 和 Primary Zone。
• Meta 租户数据不可水平扩展，只有一个日志流，不具备扩展能力。

负载均衡机制：RootService 与资源调度

RootService 作为集群的中心控制服务，基于系统租户承担着 OceanBase 数据库的大量管理工作，包括集群管理、租户管理、资源管理、负载均衡、每日合并调度、迁移复制等。RootService 通过心跳机制检测节点的健康状态，定期生成均衡计划，确保资源在节点间分布均衡。

负载均衡的层次

OceanBase 的负载均衡机制涉及两个层次：

• 租户间资源均衡（Unit 均衡）：通过在 OBServer 节点间迁移 Unit，使 Zone 内各节点的 CPU、内存资源占用率趋于一致。
• 租户内副本均衡（Leader 均衡）：Unit 迁移后，RootService 还会执行 Leader 副本的再平衡，将 Leader 尽可能分散到所有节点，避免单个节点承载全部写请求。

资源单元均衡的技术原理

RootService 在进行资源单元调度时，会计算每个 OBServer 节点的资源占用率，并通过迁移 Unit 的方式使各节点资源占用率趋于平衡。当节点间差异降至阈值以下时，调度停止。

针对多种类型资源（如 CPU 和内存），系统会为每种资源分配权重：资源占用率越高，该资源在综合计算中所占权重越高。计算节点综合资源使用率时，按权重进行归一化处理，从而使调度策略更贴近实际资源利用情况。例如，假设集群有 50 核 CPU 和 1000GB 内存，Unit 已占用 20 核 CPU 和 100GB 内存，则 CPU 使用率为 40%，内存使用率为 10%，归一化后 CPU 权重为 80%，内存权重为 20%。后续调度将基于综合使用率进行。

-- 查询资源单元均衡任务状态（sys 租户查看）
        SELECT * FROM oceanbase.DBA_OB_UNIT_JOBS WHERE JOB_TYPE = 'MIGRATE_UNIT';

        -- 查询 RootService 最近的事件历史
        SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY LIMIT 10;

Leader 均衡与路由优化

Unit 迁移后，Leader 副本分布可能出现不均衡。RootService 还会执行 Leader 的再平衡，将 Leader 副本尽可能分散到所有节点，避免单个节点承载全部写请求。在 V4.x 版本中，用户可以通过调整租户的 PRIMARY_ZONE 属性影响 Leader 的分布策略。

-- 修改租户的 Primary Zone 分布（影响 Leader 调度）
        ALTER TENANT tenant_name SET PRIMARY_ZONE = 'zone1;zone2,zone3';

        -- 开启或关闭 Leader 自动均衡（集群级）
        ALTER SYSTEM SET enable_auto_leader_switch = true;

系统租户的角色与限制

尽管引入了 Meta 租户分担压力，系统租户在 V4.x 架构中仍承担不可替代的核心职责，但它也存在明显的容量限制和单点风险。了解系统租户的定位和限制，有助于更好地理解整个资源调度体系。

系统租户的核心职责

• 管理集群和所有租户的生命周期。
• RootService 基于系统租户运行，负责资源调度和集群管理。
• 作为应用系统访问 OceanBase 数据库的入口，客户端通过 Config Server 获取系统租户 IP 列表，访问系统租户获取元数据后建立与目标租户的连接。

系统租户的限制与风险

• 扩展性受限：系统租户仅有一个 1 号日志流，只支持单点写入，不具备水平扩展能力。
• 单点风险：虽然有多副本机制保证少数节点故障时可容忍，但系统租户仍是集群的单点。因内核 Bug 导致系统租户异常会影响集群服务可用性。
• 容量挑战：大量应用同时重启时会产生连接流量尖峰，可能短时间耗尽系统租户的工作线程，导致连接建立失败。
• 不推荐业务使用：系统租户定位于集群管理和租户管理，不提供完整的数据库功能，不推荐在生产或业务测试等场合使用。

负载均衡监控视图

OceanBase 提供了丰富的视图用于监控负载均衡配置和运行状态。

核心监控视图

-- 查看集群中所有 Unit 的分布情况（sys 租户执行）
        SELECT UNIT_ID, TENANT_ID, ZONE, SVR_IP, SVR_PORT, MAX_CPU, MEMORY_SIZE, STATUS
        FROM oceanbase.DBA_OB_UNITS
        ORDER BY ZONE, SVR_IP;

        -- 查看各节点资源均衡程度（计算资源占用率差异）
        SELECT ZONE, SVR_IP, 
            MAX_CPU AS total_cpu,
            (SELECT SUM(MAX_CPU) FROM oceanbase.DBA_OB_UNITS u2 
                WHERE u2.SVR_IP = u1.SVR_IP AND u2.SVR_PORT = u1.SVR_PORT) AS used_cpu
        FROM oceanbase.DBA_OB_UNITS u1;

        -- 查看当前用户租户的 Unit 资源使用情况（用户租户执行）
        SELECT UNIT_ID, ZONE, MAX_CPU, MEMORY_SIZE/1024/1024/1024 AS memory_gb,
            STATUS, CREATE_TIME
        FROM oceanbase.GV$OB_UNITS
        WHERE TENANT_ID = (SELECT TENANT_ID FROM DBA_OB_TENANTS WHERE TENANT_NAME = USER());

        -- 查看 RootService 的近期负载均衡事件
        SELECT EVENT, VALUE, TIME 
        FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY 
        WHERE EVENT IN ('unit_balance_finished', 'unit_balance_start')
        ORDER BY TIME DESC
        LIMIT 20;

RootService（RS）是 OceanBase 集群的总控服务，运行在系统租户的 1 号日志流 Leader 所在的 OBServer 节点上，负责集群元数据管理、资源调度、负载均衡、每日合并调度、故障检测与恢复等核心职能。在 OceanBase 4.x 架构中，RootService 通过多层次的负载均衡机制，动态调整资源和数据在节点间的分布，确保集群资源利用率最大化、系统性能最优化。

RootService 的组成架构

RootService 的负载均衡由 ObRootBalancer 模块驱动，该模块包含多个策略组件，协同完成负载均衡的全流程：

核心组件说明

• ObRootBalancer：负载均衡模块的入口类，作为后台线程周期性地运行，驱动其他策略模块执行调度。
• TenantBalanceInfo：数据结构类，记录 Zone、Server、Unit、Partition、Replica 之间的交叉引用关系，为负载均衡算法提供查询接口。gather_stat() 方法负责初始化数据结构，采集当前集群的实时状态。
• ObUnitBalance：资源单元均衡的主策略类，负责决策哪些 Unit 需要迁移以及迁移到哪个目标节点。
• ObPartitionGroupCoordinator：分区组和 Unit 组调度策略的实现，负责分区（Tablet）级的负载均衡。
• ObRereplication：副本补充策略类，当分区副本数量不足时，自动生成添加副本的任务，保障数据冗余度。
• ObServerChecker：节点状态检查类，负责检测节点是否可以安全下线（如计划缩容场景），以及节点故障时的副本迁移任务。

-- 查看集群中 RootService 相关任务列表（系统租户）
        SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY
        WHERE EVENT LIKE '%balance%' OR EVENT LIKE '%migrate%'
        ORDER BY TIME DESC
        LIMIT 20;

负载均衡的层次结构

OceanBase 的负载均衡机制分为三个层次，相互独立又协同配合，共同保障集群资源的合理利用和系统的稳定运行。

层次一：租户间资源均衡（Unit 均衡）

Unit 均衡是指在 Zone 内的多个 OBServer 节点之间调度 Unit，使各节点的资源占用率（CPU、内存等）尽可能接近，避免资源闲置或单节点过载。

• 触发条件：RootService 定期检测 Zone 内 OBServer 节点的资源占用率，当节点间的资源占用率差异超过 server_balance_cpu_mem_tolerance_percent 配置的阈值（默认 5%）时，自动触发均衡调度。
• 调度单位：资源单元（Unit）是资源调度的最小单位。Unit 的分配和均衡决策由 RootService 基于 Unit 规格进行，核心目标是优化多种资源（CPU、内存等）在 Zone 内的均衡分布。

层次二：租户内数据均衡（Tablet 均衡）

Tablet 均衡是指在租户的多个 Unit 之间调整 Tablet（数据分片）的分布，使得各 Unit 的负载比较均衡。Tablet 是数据迁移、负载均衡和故障恢复的最小单位，大小通常建议控制在 2GB 左右（基于运维经验的推荐值，并非绝对限制）。

• 触发条件：当 Tablet 上的请求负载（CPU 耗时、IO 次数、网络流量）出现不均衡时，RootService 会触发 Tablet 的跨 Unit 迁移。
• 调度单位：Tablet 是数据负载均衡的最小单位。与 V3.x 版本相比，V4.x 以日志流为单元的架构使得 Tablet 均衡的粒度更细、资源开销更小。

层次三：流量均衡（Leader 均衡）

Leader 均衡是指在同 Zone 内的多个 Unit 之间调整日志流 Leader 副本的分布，使读写流量在各节点间合理分布，避免单个节点承载全部写请求。

• 触发条件：Unit 迁移后，Leader 分布可能出现不均衡。RootService 的 ObLeaderCoordinator 组件负责执行 Leader 的再平衡，将 Leader 副本尽可能分散到所有节点。
• 流量分布模型：Primary Zone 描述了 Leader 副本的偏好位置，决定了流量分布。例如，假设表 t1 的 primary_zone="Zone1"，则 RootService 会尽量将 t1 表的 Leader 调度到 Zone1 上来。

多资源类型均衡的计算模型

当集群中同时需要均衡多种类型的资源（如 CPU 和内存）时，仅依据单一资源使用率进行调度会不够精确。OceanBase 采用权重归一化算法，为每种资源分配权重，以计算节点的综合资源使用率。

权重分配策略

每种资源的权重基于其在集群总资源中的占比动态分配，资源使用越多，其权重越高。以下为一个典型计算示例：

• 集群包含：50 核 CPU、1000 GB 内存。
• 当前 Unit 已占用：20 核 CPU → CPU 使用率 40%；100 GB 内存 → 内存使用率 10%。
• 归一化计算：CPU 权重 = 40% / (40%+10%) = 80%；内存权重 = 10% / (40%+10%) = 20%。

基于权重计算每个 OBServer 节点的综合资源使用率，RootService 依据此综合指标进行 Unit 迁移调度，使均衡决策更贴近实际资源利用情况，避免单类型资源密集使用场景下的调度偏差。

单资源类型均衡示例：CPU

假设两个 OBServer 节点各有 10 个 CPU 核心：

• OBS0 包含 6 个 Unit（每个 Unit 占 1 核）→ CPU 使用率 60%。
• OBS1 包含 4 个 Unit → CPU 使用率 40%。
• 两者差异为 20%，超过默认 5% 的阈值，RootService 触发调度。
• 将 1 个 Unit 从 OBS0 迁移到 OBS1 后，两节点 CPU 使用率均为 50%，集群资源更加均衡。

Unit 迁移机制：先建后删的流程

为保证迁移过程中读写不中断，Unit 迁移采用“先建后删”的流程。迁移目标必须与源在同一个 Zone 内，且目标节点有足够的资源承载。

迁移流程

• 创建目标 Unit：在目标节点上创建新的 Unit 副本。
• 同步数据：将源 Unit 中的数据同步到目标 Unit（通过日志同步）。
• 切换租户 Unit 列表：将目标 Unit 加入租户的 Unit 列表，同时将源 Unit 标记为待迁移状态。
• 删除源 Unit：数据同步完成且服务切换后，删除源 Unit，释放资源。

-- 查询 Unit 迁移任务（系统租户）
        SELECT * FROM oceanbase.DBA_OB_UNIT_JOBS WHERE JOB_TYPE = 'MIGRATE_UNIT';

        -- 查询 RootService 调度事件（近期负载均衡记录）
        SELECT EVENT, VALUE, TIME 
        FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY 
        WHERE EVENT IN ('unit_balance_finished', 'unit_balance_start', 'tablet_balance_finished')
        ORDER BY TIME DESC
        LIMIT 20;

Primary Zone 与 Leader 调度

Leader 副本承载了业务的强一致读写流量，其分布决定了流量分布。Primary Zone 通过 Zone 优先级列表来指定 Leader 的偏好位置，RootService 会优先将 Leader 调度到优先级最高的 Zone 上。

Primary Zone 优先级规则

• 分号（;）：表示不同的优先级等级，排在左侧的优先级更高。例如：'hz1,hz2;sh1,sh2;sz1' 表示 hz1/hz2 优先级高于 sh1/sh2，sh1/sh2 优先级高于 sz1。
• 逗号（,）：表示相同优先级，流量均匀打散在同优先级的 Zone 上。
• Leader 调度时，RootService 会按照优先级顺序尝试在 Zone 上设置 Leader，只有高优先级 Zone 的副本不可用时才会调度到低优先级 Zone。

Primary Zone 的继承与层级

Primary Zone 支持多种粒度的配置。在 OceanBase V4.x 中，仅支持租户级别的 Primary Zone。V3.x 曾支持表级、表组级、数据库级等更细粒度的配置，但 V4.x 将管理粒度提升到租户级以简化运维。

切主动能（Leader Switch）

除了负载均衡驱动的 Leader 自动调度，RootService 还支持按需主动切主。当需要调整 Leader 分布时（如 Primary Zone 变更、节点维护），RootService 会根据新的 Primary Zone 优先级平滑地迁移 Leader，切主过程对业务透明，不会造成中断。

故障检测与自动处理

RootService 通过心跳机制实时监测各 OBServer 的健康状态，OBServer 默认每 2 秒向 RootService 发送一次心跳包。RootService 依据心跳包的接收状态判断节点状态，并自动执行对应的故障处理。

心跳超时检测与故障处理流程

RootService 状态监控与运维

OceanBase 提供了多个视图用于监控 RootService 的运行状态和负载均衡任务进度，从 V4.0.0 版本开始引入。

核心监控视图

-- 系统租户查看集群中所有 Unit 的分布情况
        SELECT UNIT_ID, TENANT_ID, ZONE, SVR_IP, SVR_PORT, MAX_CPU, MEMORY_SIZE, STATUS
        FROM oceanbase.DBA_OB_UNITS
        ORDER BY ZONE, SVR_IP;

        -- 用户租户查看本租户 Unit 资源使用情况
        SELECT UNIT_ID, ZONE, MAX_CPU, MEMORY_SIZE/1024/1024/1024 AS memory_gb,
            STATUS, CREATE_TIME
        FROM oceanbase.GV$OB_UNITS
        WHERE TENANT_ID = (SELECT TENANT_ID FROM DBA_OB_TENANTS WHERE TENANT_NAME = USER());

        -- 查看 RootService 的近期负载均衡事件（排查调度问题）
        SELECT EVENT, VALUE, TIME 
        FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY 
        WHERE EVENT IN ('unit_balance_finished', 'unit_balance_start', 'tablet_balance_finished')
        ORDER BY TIME DESC
        LIMIT 30;

        -- 查询 Unit 迁移任务进度
        SELECT * FROM oceanbase.DBA_OB_UNIT_JOBS WHERE JOB_TYPE = 'MIGRATE_UNIT';

负载均衡运维最佳实践

在 OceanBase 4.x 架构中，租户的参数配置是保障数据库高性能、高可用的关键环节。通过合理的参数设置，可以使数据库行为更贴合业务需求，充分发挥硬件性能。OceanBase 提供了多层次的参数体系和场景化的推荐配置模板，帮助 DBA 高效完成租户的参数配置与管理。

OceanBase 配置管理概览

OceanBase 数据库的配置管理通过系统配置项（Parameters）和系统变量（Variables）两个维度来实现。理解二者的区别是正确配置租户的基础。

系统配置项与系统变量的对比

-- 查询集群级配置项（系统租户）
        SHOW PARAMETERS LIKE 'enable_rebalance';

        -- 查询租户级配置项（系统租户或用户租户）
        SHOW PARAMETERS LIKE 'ob_tcp_invited_nodes';

        -- 查询租户级 Global 变量（推荐在用户租户下执行）
        SHOW GLOBAL VARIABLES LIKE 'ob_query_timeout';

        -- 修改租户级 Global 变量（推荐在用户租户下执行）
        SET GLOBAL ob_query_timeout = 20000000;   -- 设置为 20 秒

租户参数模板管理

从 V4.3.2 版本开始，OceanBase 在安装包的 /home/admin/oceanbase/etc 目录下提供了多场景的参数推荐配置模板。参数模板会预先将租户的参数设置好，在需要创建配置相似的一系列租户的场景下，可直接应用参数模板，如此可不必反复配置租户参数。从 V4.3.1 版本开始，OCP 平台也支持可视化的租户参数模板管理。

内置参数模板类型

OceanBase 提供了五种预置的参数模板，覆盖主流业务场景：

场景化参数最佳实践

以下针对 V4.3.x 版本的推荐参数配置，综合了 OceanBase 在各行业客户的大量实战调优经验。具体配置值可能因版本迭代有所差异，建议以版本自带模板为准。

一、OLTP 场景推荐参数

OLTP 场景追求高并发、低延迟的事务处理，参数配置重点在于保障小事务的响应速度。

-- OLTP 场景参数配置示例（sys 租户执行）
        ALTER SYSTEM SET _enable_defensive_check = 0;
        ALTER SYSTEM SET enable_syslog_recycle = True;
        ALTER SYSTEM SET max_syslog_file_count = 300;

        -- 租户级参数配置（用户租户执行）
        SET GLOBAL _rowsets_max_rows = 256;
        SET GLOBAL log_transport_compress_all = True;

二、复杂 OLTP 场景推荐参数

复杂 OLTP 场景涉及复杂查询、长事务、PL 批处理等，需要适当放宽大查询阈值，平衡复杂操作与小事务的性能。

三、AP/HTAP 场景推荐参数

AP 和 HTAP 场景追求分析查询的快速响应，参数配置重点在于保障大规模扫描和并行执行的能力。

-- AP/HTAP 场景参数配置示例（sys 租户执行）
        ALTER SYSTEM SET large_query_threshold = '600s';
        ALTER SYSTEM SET enable_record_trace_log = false;
        ALTER SYSTEM SET enable_syslog_recycle = True;
        ALTER SYSTEM SET max_syslog_file_count = 300;

        -- 租户级配置（用户租户执行）
        SET GLOBAL log_transport_compress_all = True;

租户核心系统变量推荐配置

租户级系统变量直接控制 SQL 执行行为，以下为生产环境常用的配置建议：

常用租户系统变量配置表

-- 租户变量配置示例（用户租户下执行）
        -- 调整 SQL 超时时间为 30 秒
        SET GLOBAL ob_query_timeout = 30000000;

        -- 设置 IP 白名单（允许任意 IP 访问，生产环境请按需收紧）
        SET GLOBAL ob_tcp_invited_nodes = '%';

        -- 开启弱一致性读（需配合 LDC 使用）
        SET GLOBAL read_consistency = 'WEAK';

        -- 开启 Auto DOP（自动并行度）
        SET GLOBAL parallel_degree_policy = 'AUTO';

        -- 开启 Runtime Filter 优化复杂 Join（系统变量默认值为空字符串）
        SET GLOBAL runtime_filter_type = 'BLOOM_FILTER,RANGE,IN';

租户资源参数优化

租户的资源参数在创建资源单元（Unit Config）时定义，决定了租户获得的物理资源上限。合理的资源分配是性能保障的基础。

资源单元配置建议

-- 创建生产环境资源单元示例
        CREATE RESOURCE UNIT prod_unit 
            MAX_CPU=16, MIN_CPU=16,        -- CPU 不超卖
            MEMORY_SIZE='64G', 
            MAX_IOPS=128000, MIN_IOPS=128000, 
            LOG_DISK_SIZE='128G';          -- 日志盘为内存 2 倍

        -- 创建资源池
        CREATE RESOURCE POOL prod_pool 
            UNIT='prod_unit', 
            UNIT_NUM=1, 
            ZONE_LIST=('zone1','zone2','zone3');

        -- 创建租户并应用参数模板
        CREATE TENANT prod_tenant 
            RESOURCE_POOL_LIST=('prod_pool')
            PRIMARY_ZONE='RANDOM'
            CHARSET='utf8mb4'
            SET ob_compatibility_mode='mysql', 
                ob_tcp_invited_nodes='10.0.0.0/8';

        -- 查看租户创建结果
        SELECT TENANT_ID, TENANT_NAME, PRIMARY_ZONE, COMPATIBILITY_MODE 
        FROM oceanbase.DBA_OB_TENANTS 
        WHERE TENANT_NAME = 'prod_tenant';

租户参数模板与最佳实践汇总

V4.3.x 版本模板配置文件位置

OceanBase 安装包的 RPM 包安装后，可在以下目录找到场景化的参数推荐模板：

/home/admin/oceanbase/etc/
        ├── default_parameter.json          # 参数推荐配置（通用）
        └── default_system_variable.json    # 系统变量推荐配置（通用）

各场景的具体配置值分布在模板文件中，供 OCP 和 OBD 等运维工具读取使用。

向量化执行（Vectorized Execution）是一种高效的按批处理数据的技术，是数据库系统从传统行式执行（火山模型）向批量处理演进的关键里程碑。在分析型查询中，向量化执行可以大幅提升执行性能，充分发挥现代 CPU 的并行计算能力。OceanBase 从 3.2 版本引入向量化执行引擎，从 4.0 版本开始默认开启，并在 4.3 版本推出了向量化引擎 2.0，通过对数据格式、算子实现和存储层的全面优化，实现了执行性能的又一次飞跃。

从火山模型到向量化执行

要理解向量化引擎，首先需要了解传统的查询执行模型——火山模型（Volcano Model）。火山模型自 1990 年在论文《Volcano, an Extensible and Parallel Query Evaluation System》中被提出以来，被 Oracle、MySQL、DB2、SQL Server 等主流关系型数据库广泛采用。

火山模型通过解耦算子逻辑，能够优雅地将任意算子组装成执行树，但该模型在现代 CPU 架构下存在明显的性能瓶颈：

• 框架函数调用开销巨大：每处理一行数据都需要一次虚函数调用，处理 1 亿行数据就需要调用 1 亿次 get_next_row()，CPU 资源浪费严重。
• CPU 缓存利用率低：频繁的函数调用和分支判断导致指令缓存（ICache）命中率下降。
• 数据依赖严重：单行处理限制了指令级并行（ILP）和超标量执行能力。
• 内存带宽浪费：逐行访问导致大量随机内存访问，无法有效利用 CPU 预取机制。

向量化执行的核心原理：从逐行到批量

向量化引擎通过在火山模型基础上引入批量处理能力，将一次迭代处理一行数据转变为一次处理一批数据，从根本上突破火山模型的性能瓶颈。

批次处理的收益分析

执行计划中通过 rowset=N 标识向量化处理时的批次大小。例如，在执行计划中看到如下信息：

|0 - output([T_FUN_COUNT_SUM(T_FUN_COUNT(*))]), filter(nil), rowset=16

其中 rowset=16 表示该算子一次处理 16 行数据。该参数会依据系统资源（CPU 核心数、内存大小）和 SQL 类型（TP/AP）自适应调整，最佳实践是不手动修改。

OceanBase 向量化引擎的技术演进

OceanBase 向量化引擎经历了从 V3.2 引入到 V4.3 引擎 2.0 的持续演进，每一阶段都有明确的技术目标和性能提升。

版本演进路线图

向量化引擎 1.0 的局限性

在向量化引擎 1.0 实现中，存储层数据投影后，某列表达式的一批数据在内存中的组织格式是由多个连续的数据描述单元（包含 null 描述、数据长度 len 及数据指针 ptr）及实际数据组成，存在以下问题：

• 读写访问不够高效：每次访问都需要先获取数据描述单元，然后通过 ptr 间接访问数据，不能直接访问。
• 内存使用更多：以 N 行 int32_t 数据为例，数据描述单元占 12 字节，总内存为 N × (12+4) 字节，而实际数据仅需 N × 4 字节，空间放大 4 倍。
• SIMD 计算不够友好：一批数据对应的实际数据不一定连续存放，难以利用 SIMD 指令并行计算。
• 序列化/物化开销更多：需要进行指针的 swizzling 操作，即将指针转换为相对偏移，效率低下。

向量化引擎 2.0 的关键优化：数据格式革新

为优化向量化 1.0 数据格式带来的不足，向量化引擎 2.0 实现了新的按列的数据格式。将数据描述信息（null、len、ptr）按列分开连续存放，避免数据信息冗余存储。针对不同数据类型和使用场景，实现了三种数据格式：

• 定长数据格式：仅需 null bitmap 和连续的数据，length 信息存放一份即可。相比引擎 1.0，数据无冗余存放、节省空间，直接访问性能更好，数据连续对 SIMD 更友好，物化/序列化无需指针 swizzling。
• 变长离散格式：每个数据在内存中可能不连续存放，使用数据地址指针和长度描述，长度和指针信息按列连续存放。适合存储层为编码数据、需要投影但不需要深拷贝数据的场景，支持短路计算。
• 变长连续格式：数据连续存放在内存中，长度信息和偏移地址使用 offset 数组描述。数据访问和按批复制效率更高，但短路计算和列存编码投影不友好，主要用于按列物化场景。

算子及表达式全面优化

向量化引擎 2.0 不仅优化了数据格式，还对算子及表达式实现进行了全面重构，主要优化思路包括：

• 利用 Batch 数据属性信息：批次数据的元信息（如是否全部为 NULL、是否全部满足某个条件）可用于跳过不必要的计算逻辑。
• 算法数据结构优化：Sort、Hash Join、Hash Group By、数据 Shuffle、聚合计算等核心算子按新格式重新设计与实现。
• 表达式特化实现：针对常用表达式提供特化版本，减少通用的分支判断开销。

这些优化共同减少了 CPU 数据 Cache Miss，降低了 CPU 分支预测错误及 CPU 指令开销，显著提升了整体执行性能。

存储层向量化读取

向量化引擎的优化不仅仅在 SQL 层，更深入到存储引擎层。通过存储层向量化读取，实现了从存储到计算的全链路向量化处理。

• 存储向量化：存储引擎在读取 SSTable 时，可以一批次读取多个微块（Microblock），并以列存格式组织返回给 SQL 层。
• 谓词下压向量化：过滤条件可以下压至存储层，在读取数据时完成向量化的过滤判断，减少向上层传递无效数据。
• 行列存统一支持：在行存模式下，OceanBase 已实现向量化存储引擎的无缝对接，无需任何修改即可支持向量化执行。

对现代 CPU 的深度优化

OceanBase 向量化引擎通过三层优化深度适配现代 CPU 架构，最大化发挥 CPU 性能：

• 数据紧凑排列，提升 CPU Cache 友好性：批量数据按列组织并紧凑存储，CPU 在顺序读取数据时可充分发挥硬件预取机制，L1/L2/L3 缓存命中率显著提高。
• SIMD 指令加速：向量化 2.0 将数据存储格式调整为列式，使连续内存的批量计算更易利用 SIMD 指令（如 AVX512）实现并行处理。
• Batch 级别属性判断：利用批次数据的整体特征（如全 NULL、全满足某条件）跳过逐行判断逻辑，减少无效计算开销。

性能测试与收益

向量化引擎的性能提升在多个基准测试和生产场景中得到了充分验证：

历史成绩（V3.2 时代）

2021 年，OceanBase 凭借向量化引擎的贡献，以 1526 万 QphH@30000GB 的性能成绩，创造了 TPC-H 分析型基准测试新的世界纪录，排名第二。

V4.3 版本对比测试

在 TPC-H 30TB 数据集测试中：

• 向量化引擎整体性能是非向量化的 2.48 倍。
• 对于 Q1 这种聚合分析且计算密集的 SQL 查询，性能提升约 10 倍。

从 V4.3.0 到 V4.3.3 GA 版本，TPC-H 1TB 数据集的查询性能从 99 秒提升至 60 秒，实现了 64% 的性能提升。

跨版本持续优化

相比 V4.2.1 版本，V4.3 版本的 TPC-H 和 TPC-DS 性能分别提升 25% 和 111%。

向量化引擎与 AI 预处理

向量化引擎不仅服务于传统 AP 场景，还在 AI 生态中扮演着重要角色。AI 模型的训练与推理依赖大规模高质量数据的高效预处理（如特征工程、数据清洗、统计分析等 AP 场景任务）。OceanBase 向量化引擎通过大幅提升大规模数据的分析处理能力，可快速完成 AI 所需的海量数据预处理工作，缩短数据到模型的流转周期，为 AI 应用提供稳定、高效的底层数据存储与计算底座。

并行执行（Parallel Execution）通过利用多个 CPU 核心来加速大规模数据处理的查询，是数据库系统用于处理分析型查询的核心技术之一。然而，如何为不同的查询合理地设置并行度（Degree of Parallelism，DOP），以达到加速查询和避免资源过度消耗之间的平衡，是一个实践难题。针对手动指定并行度的痛点，Auto DOP 功能应运而生，它让优化器能够根据查询的实际需求，自动判断是否开启并行执行，并选择合适的并行度，从而实现并行度的“自动驾驶”。

从手动指定到自动选择

OceanBase 优化器的并行度 DOP 选择策略目前分为AUTO 模式和MANUAL 模式，选择 AUTO 模式即为 Auto DOP。[reference:0]

您可以通过 MANUAL 模式手动指定并行度，一种方式是使用系统变量对当前会话中的所有执行查询开启并行执行并指定并行度，但这可能会给会话中本不需要并行加速，或者不需要使用较高 DOP 的查询带来额外的开销，从而导致性能下降；另一种方式是通过 Hint 来指定特定查询的并行度，但这需要对每一条业务查询进行单独考量，对于存在大量业务查询的场景是不可行的。[reference:1]

基于手动指定并行度所带来的不便和限制，AUTO 模式应运而生。OceanBase 数据库查询优化器的 Auto DOP 功能，在生成查询计划时会评估查询所需要执行的时间，自动确定是否开启并行以及确定对当前查询合适的并行度，避免了由于手动指定并行度而导致的性能下降问题。[reference:2]

如何开启 Auto DOP 策略

OceanBase 数据库优化器通过系统变量 parallel_degree_policy 进行 GLOBAL 和 SESSION 级别的 Auto DOP 选择策略配置，也可通过更高优先级的 Hint 进行查询级别的 DOP 选择策略配置。

-- 在 GLOBAL 级别启用 Auto DOP
        SET GLOBAL parallel_degree_policy = AUTO;

        -- 在 SESSION 级别启用 Auto DOP
        SET SESSION parallel_degree_policy = AUTO;

        -- 在 GLOBAL 级别禁止 Auto DOP
        SET GLOBAL parallel_degree_policy = MANUAL;

        -- 使用 Hint 在查询级别启用 Auto DOP
        SELECT /*+PARALLEL(AUTO)*/ * FROM ...;

        -- 使用 Hint 在查询级别禁止 Auto DOP
        SELECT /*+PARALLEL(MANUAL)*/ * FROM ...;
        -- 或者直接指定一个固定的 DOP（例如 8）
        SELECT /*+PARALLEL(8)*/ * FROM ...;

以上示例参考自 OceanBase 官方文档。[reference:9]

并行开启方式及优先级

OceanBase 数据库支持通过 Auto DOP、Hint、系统变量、Schema DOP 等多种方式对查询开启并行执行。在查询支持并行执行的前提下，多种并行开启方式的优先级（由高到低）如下：表级并行 Hint 配置 DOP > 全局并行 Hint 配置 DOP > 系统变量配置 DOP > Schema DOP。[reference:10]

其中，全局并行 Hint 可以通过设置 PARALLEL(AUTO) 来指定查询使用 Auto DOP 策略，或通过设置 PARALLEL(MANUAL) 来禁止 Auto DOP，也可以直接使用 PARALLEL(dop_value) 来为一个查询中的所有表指定一个固定的 DOP。由于全局并行 Hint 优先级低于表级并行 Hint，当同时存在全局和表级并行 Hint 时，全局 Hint 仅对没有表级 Hint 生效的表生效。[reference:11]

-- 全局并行 Hint：指定查询中所有表使用 DOP = 8
        SELECT /*+PARALLEL(8)*/ * FROM t1, t2 WHERE t1.c1 = t2.c1;

        -- 全局并行 Hint：指定查询中所有表使用 Auto DOP 策略
        SELECT /*+PARALLEL(AUTO)*/ * FROM t1, t2 WHERE t1.c1 = t2.c1;

        -- 表级并行 Hint 与全局并行 Hint 组合使用
        -- 表 t1 因表级 Hint 使用 DOP = 8，表 t2 因全局 Hint 使用 DOP = 4
        SELECT /*+PARALLEL(t1 8) PARALLEL(4)*/ * FROM t1, t2 WHERE t1.c1 = t2.c1;

        -- 表级并行 Hint 与 Auto DOP 组合使用
        -- 表 t1 因表级 Hint 使用 DOP = 8，表 t2 根据 Auto DOP 策略自动获取 DOP
        SELECT /*+PARALLEL(t1 8) PARALLEL(AUTO)*/ * FROM t1, t2 WHERE t1.c1 = t2.c1;

以上示例参考自 OceanBase 官方文档。[reference:12]

Auto DOP 核心参数

为了在生产环境中安全且高效地使用 Auto DOP，需要了解并合理配置以下几个关键参数，它们共同构成了 Auto DOP 的资源管控与执行优化体系。

• parallel_servers_target：租户级别的系统变量，它明确规定了租户在每个节点上可申请的并行执行线程数量。其默认值是 MIN CPU * px_workers_per_cpu_quota。当这个参数指定的线程资源耗尽时，后续发起的并行执行请求需要进入排队等待的状态，直至有可用资源释放。[reference:14]
• parallel_degree_limit：用于设置在使用 Auto DOP 策略时，优化器选择并行度的上限值。该变量从 V4.2.0 版本开始引入。默认值为 0，表示对并行度不进行限制。当 parallel_degree_limit = 0 时，系统会自动借助 CPU 资源状况和 parallel_servers_target 的设定，共同限制最大 DOP 值。[reference:15]
• parallel_min_scan_time_threshold：以毫秒（ms）为单位，默认值设置为 1000 ms，该参数对并行度的调整有着直接影响。具体来说，当基表的扫描代价高于该参数设定的值时，系统就会自动开启并行处理模式。假如适当调小该值，可以降低基表开启并行处理的门槛，使得评估执行时间更短的基表扫描也能被纳入并行处理范畴。[reference:16]

-- 设置租户级 Auto DOP 并行度上限（例如 32）
        SET GLOBAL parallel_degree_limit = 32;

        -- 开启 Auto DOP
        SET GLOBAL parallel_degree_policy = AUTO;

Auto DOP 适用场景与风险

Auto DOP 仅基于查询执行成本进行评估，以减小响应时间（RT）为目标来决定是否启用并行处理及计算 DOP。若业务负载中包含对用户不关心的慢查询，则功能开启后这些查询可能会以并行方式执行，并获得较高的并发度。这些查询的并行执行将占用系统并行资源，对其他需要正常并发处理、优化响应时间的查询造成干扰。若这些查询占用过多资源，系统 CPU 负载将急剧上升，严重影响正常业务查询。[reference:17]

Auto DOP 只能优化针对当前查询响应时间（RT）的目标，而不会考虑系统中存在大量需要并发处理的查询场景。因此，在实际业务系统中使用 Auto DOP 功能，需要根据实际优化目标，有针对性地调整相关系统变量。特别是当 AP 慢查询开启 Auto DOP 占用大量线程并行执行时，会在一定程度上影响分配给小查询的资源。[reference:18]

为此，OceanBase 官方文档提供了两种使用场景：

• 场景 1：查询性能极致优化：追求单条查询的极致性能优化，使用 Auto DOP 功能。此场景下，建议在使用 Auto DOP 的基础上配置适当的资源组或资源配置（比如 parallel_servers_target、parallel_degree_limit 等），作为兜底策略，以避免单个查询占用过多并行执行资源，对系统造成负面影响。[reference:19]
• 场景 2：系统性能优化：追求系统整体性能最优，不使用 Auto DOP，而是使用资源隔离策略，控制不同负载对资源的占用。[reference:20]

当用户访问分区表时，往往只需要访问其中的部分分区。优化器根据 SQL 中的 WHERE 条件，自动识别需要访问的分区，直接跳过不需要的分区，只扫描目标数据分区——这一优化过程称为分区裁剪（Partition Pruning）。它是分区表最重要的优化手段，通过分区裁剪，SQL 的执行效率可以得到大幅度提升。

分区裁剪的基本原理

分区裁剪由 OceanBase 数据库优化器的 Query Range 子模块完成。优化器根据表的分区信息和 SQL 中指定的条件，抽取出相关的分区信息，计算出需要访问的分区集合。核心触发条件是：WHERE 子句中必须包含分区键的过滤条件。

HASH / LIST 分区裁剪

对于 HASH 分区和 LIST 分区，分区裁剪的基本原理是：根据 WHERE 子句中的条件计算分区列的值，通过结果判断需要访问哪些分区。HASH 和 LIST 分区仅支持等值条件裁剪，不支持范围查询裁剪。此外，如果分区条件为表达式，且该表达式作为一个整体出现在等值条件里，也可以进行分区裁剪。

-- 示例：HASH 分区，WHERE 条件为分区键等值，可触发裁剪
        CREATE TABLE tbl1(col1 INT, col2 INT) PARTITION BY HASH(col1) PARTITIONS 5;

        EXPLAIN SELECT * FROM tbl1 WHERE col1 = 1;

        -- 执行计划结果（仅访问分区 p1）
        -- 关键信息：partitions(p1)
        -- |0 |TABLE FULL SCAN|tbl1|1|4|
        -- Outputs & filters: 0 - output([tbl1.col1], [tbl1.col2]),
        --   filter([tbl1.col1 = 1]), access([tbl1.col1], [tbl1.col2]), partitions(p1)

        -- 示例：分区条件为表达式，整体出现在等值条件中，也可裁剪
        CREATE TABLE t1_h (c1 INT, c2 INT) PARTITION BY HASH(c1 + c2) PARTITIONS 5;

        EXPLAIN SELECT * FROM t1_h WHERE c1 + c2 = 1;

        -- 执行计划结果（同样仅访问一个分区）
        -- 关键信息：partitions(p1)

RANGE 分区裁剪

对于 RANGE 分区，通过 WHERE 子句中分区键的范围与表定义的分区范围取交集来确定需要访问的分区。RANGE 分区支持等值、大于、小于、区间范围等多种裁剪方式，是业务中最稳定、最常用的分区类型，特别适用于时序日志、交易流水、订单数据等场景。

-- 示例：RANGE 分区支持范围查询裁剪
        -- 分区定义（假设 c1 为分区键）
        -- PARTITION p0 VALUES LESS THAN (100), p1 VALUES LESS THAN (200), p2 VALUES LESS THAN (MAXVALUE)

        -- 查询条件为范围区间
        SELECT * FROM t1 WHERE c1 >= 120 AND c1 < 180;

        -- 优化器计算交集后，仅需要访问 p1 分区

二级分区裁剪原理

对于二级分区（子分区）表，分区裁剪需要同时满足一级分区键和二级分区键的条件，才能实现精准裁剪。

• 裁剪流程：首先根据一级分区键条件确定需要访问的一级分区，然后根据二级分区键条件进一步确定需要访问的二级分区，最终取两者的笛卡尔积得出需要访问的物理分区集合。
• 裁剪不彻底的风险：如果查询条件中只包含一级分区键条件而未包含二级分区键条件，则只能裁剪到一级分区层级，二级分区层面仍需扫描全部子分区，裁剪不完全。

优化器的执行机制

OceanBase 数据库的分区裁剪由 Query Range 子模块执行，其核心工作流程如下：

1. 条件解析：从 WHERE 子句中提取与分区键相关的过滤条件。
2. 分区范围计算：将过滤条件与表的分区定义进行匹配计算，生成需要访问的分区列表。
3. 指定分区与裁剪结果的交集：如果 SQL 中直接指定了分区（通过 PARTITION 语法），优化器会取“指定分区”和“裁剪结果”的交集作为最终访问的分区集合。
4. 裁剪失效时的退化处理：若 WHERE 条件中不包含分区键，优化器将无法进行分区裁剪，此时会进行全分区扫描，导致 I/O 和 CPU 消耗显著增加。

执行计划验证

通过 EXPLAIN 命令可以查看执行计划并确认分区裁剪是否生效。执行计划输出中的关键信息有两个来源：

• access() 行中的 partitions 字段：明确列出当前查询实际需要访问的分区集合。例如 partitions(p1) 表示仅访问 p1 分区；partitions(p[0-1]) 表示访问 p0 和 p1 两个分区。
• 算子层级的信息：在执行计划树中，分区裁剪的信息也会通过 PARTITION RANGE ITERATOR 等算子的形式显示，表明系统正在通过分区范围迭代器访问限定分区。

-- 通过 EXPLAIN 查看分区裁剪结果
        EXPLAIN SELECT * FROM tbl1 WHERE col1 = 1;

        -- 输出中的关键行：
        -- 0 - output(...), filter(...), access(...), partitions(p1)
        -- 
        -- partitions(p1) 表示分区裁剪成功生效，仅访问 p1 分区；
        -- 若显示 partitions(p[0-4]) 或未显示 partitions 字段，则表示裁剪未生效或全分区扫描。

性能收益分析

分区裁剪对查询性能的提升在数据量大的场景下尤为显著，主要体现在以下维度：

• I/O 减少：仅扫描目标分区数据，磁盘读取量大幅降低。
• 扫描数据量对比：如上文日志表示例（30 个分区），裁剪生效时仅扫描 1/30 的数据；裁剪失效时扫描全量数据，I/O 放大 30 倍。
• CPU 和内存节省：减少无效数据的读取和处理，节约计算资源。
• 支撑业务报表实时性：在数仓、报表等业务场景中，分区裁剪是保障查询实时性的关键技术。客如云智享版报表通过分区化改造，基于分区裁剪大幅提升了报表查询性能。

分区裁剪失效是导致分区表查询性能下降的最常见原因。很多开发者误以为“建了分区就一定会变快”，实际上分区表能否提速，核心取决于能否有效触发分区裁剪。一旦分区裁剪失效，查询不仅无法获得性能提升，反而会因全分区扫描和额外的元数据开销，导致查询效率甚至低于普通单表。本节从日常开发、数仓查询、业务报表等真实场景出发，整理高频失效陷阱及对应的排查方法与修复策略。

5 类高频失效陷阱

以下是日常开发、数仓及报表场景中高频遇到的真实踩坑点，覆盖约 90% 的裁剪失效问题。

场景 1：分区键进行了函数运算或类型转换

对分区键进行函数处理（如日期格式化、截取、数值运算等）或触发隐式类型转换，会直接导致优化器无法识别分区范围，只能执行全分区扫描。核心原则：分区键禁止做函数、运算、类型转换。

-- ❌ 错误写法：对分区键包裹函数、运算
        SELECT * FROM orders WHERE DATE(created_at) = '2025-01-01';
        SELECT * FROM orders WHERE created_at + 1 = 20250101;

        -- ✅ 正确写法：通过区间范围匹配，不对分区键做任何函数包裹
        SELECT * FROM orders WHERE created_at >= '2025-01-01' AND created_at < '2025-01-02';

        -- ❌ 错误示例：分区键是时间类型，却传入字符串类型，触发隐式转换
        SELECT * FROM orders WHERE created_at = '2025-01-01 00:00:00';
        -- ✅ 正确示例：保证查询条件字段类型与分区键类型完全一致
        SELECT * FROM orders WHERE created_at = TIMESTAMP '2025-01-01 00:00:00';

场景 2：查询条件中缺少分区键或使用了 OR 连接

查询条件中不包含分区键是最基础也最常见的裁剪失效场景。时序日志表分区时业务开发规范必须强制携带分区键条件，否则优化器无法定位目标分区。同时 OR 条件中只要有一个分支缺少分区键或导致裁剪逻辑无法合并，整体裁剪就会失效。

-- ❌ 错误写法：缺少分区键过滤条件，导致全分区扫描
        SELECT * FROM orders WHERE order_status = 'PAID';

        -- ❌ 错误写法：OR 条件中部分条件无法定位分区
        SELECT * FROM orders WHERE id = 10086 OR created_at = '2025-01-01';

        -- ✅ 正确写法：WHERE 子句中必须包含分区键过滤条件
        SELECT * FROM orders WHERE created_at >= '2025-01-01' AND created_at < '2025-01-02';

场景 3：分区键为 NULL 值或使用了非确定性函数

当分区键字段允许 NULL 值且查询条件包含 IS NULL 或 IS NOT NULL 时，优化器无法精准定位分区，可能触发大部分分区扫描。同理，使用 CURRENT_DATE、NOW() 等非确定性函数进行分区键过滤，优化器无法在计划生成阶段确定具体分区范围，也会导致分区裁剪失效。

-- ❌ 错误示例：分区键使用 IS NULL 条件，优化器无法精准定位
        SELECT * FROM orders WHERE partition_key IS NULL;

        -- ✅ 改进方案：避免分区键为 NULL，或与业务设计结合将 NULL 映射为特殊值
        SELECT * FROM orders WHERE partition_key = 0;  -- 以 0 代表空值，迁移数据时统一处理

        -- ❌ 错误示例：分区键使用 CURRENT_DATE 函数，优化器无法确定具体分区
        SELECT * FROM orders WHERE created_at = CURRENT_DATE;
        -- ✅ 正确示例：使用具体常量值
        SELECT * FROM orders WHERE created_at = '2025-01-01';

场景 4：子查询或关联查询中的连接条件无法推导分区键

当分区键的过滤条件来自子查询或 JOIN 关联条件，且优化器无法推导出具体分区范围时，分区裁剪可能失效。

-- ❌ 错误示例：分区键在 IN 子句中依赖子查询结果
        SELECT * FROM orders WHERE created_at IN (SELECT max_date FROM date_config);

        -- ✅ 改进方案：先执行子查询，再将结果传递给外层查询（例如通过临时表）
        CREATE TEMPORARY TABLE temp_date AS SELECT max_date FROM date_config;
        SELECT * FROM orders WHERE created_at IN (SELECT max_date FROM temp_date);

场景 5：统计信息过时导致优化器误判

即便查询条件包含了分区键且未做函数运算，优化器也可能因统计信息过时，在成本估算时误判全分区扫描“代价更低”，从而在部分节点“突然”放弃分区裁剪。

-- 定期收集统计信息，确保优化器获得准确的行数和分布数据
        ANALYZE TABLE orders COMPUTE STATISTICS;
        -- 或使用 DBMS_STATS 系统包（推荐）
        CALL DBMS_STATS.GATHER_TABLE_STATS('TEST', 'ORDERS');

        -- 查看统计信息最后更新时间
        SELECT TABLE_NAME, LAST_ANALYZED, NUM_ROWS 
        FROM oceanbase.DBA_TAB_STATISTICS 
        WHERE TABLE_NAME = 'ORDERS';

二级分区裁剪的特殊性

二级分区的裁剪机制遵循“先一级、后二级”的逻辑[reference:13]，其裁剪效果取决于条件组合，需要特别注意：

-- ❌ 裁剪不彻底：只包含一级分区键
        -- 一级分区条件可定位到一级分区，但该分区下所有二级分区仍需扫描
        SELECT * FROM orders_by_day_and_category 
        WHERE order_date = '2025-01-01';

        -- ✅ 完全剪枝：同时包含两级分区键条件
        SELECT * FROM orders_by_day_and_category 
        WHERE order_date = '2025-01-01' AND category = 'ELECTRONICS';

开发规范与优化建议

OBProxy（OceanBase Database Proxy，也称 ODP）是 OceanBase 数据库专用的反向代理服务。在分布式的 OBServer 集群与客户端之间，OBProxy 通过 SQL 路由与容灾机制，屏蔽了底层分布式架构的复杂性，让应用访问 OceanBase 如同访问单机数据库。OBProxy 本身具备高可用（HA）设计，是 OceanBase 整体高可用体系的关键组成部分。

无状态：OBProxy 高可用的核心基础

OBProxy 的高可用能力根植于其无状态的设计理念。与数据库引擎不同，OBProxy 不存储任何会话状态、路由表或事务上下文信息。这一设计带来了以下关键优势：

• 极致的故障恢复能力：任意一个 OBProxy 实例故障时，客户端的请求可以被负载均衡器（如 F5、SLB、HAProxy）自动调度到其他健康的 OBProxy 实例上，故障节点对整个业务链路完全透明。同时，OBProxy 在部署时会带有一个守护进程 obproxyd.sh，周期性检查 OBProxy 的健康程度，一旦发现宕机就立即重启。
• 弹性水平扩展：添加或删除 OBProxy 实例无需数据迁移或状态同步，系统管理员可按业务流量变化灵活调整实例数量。
• 简化运维：支持通过丰富的内部命令对 OBProxy 状态进行实时监控，运维人员可以从容应对版本升级和节点替换。

OBProxy 的部署方式

OBProxy 作为 OceanBase 的接入层，支持多种部署模式，以适应不同环境的需求。

合并部署

在合并部署模式下，ODP 与 OBServer 部署在同一台服务器上。该模式适用于私有云或资源受限的场景，通常以 OCP 方式启动，可以访问多个集群。当 OCP 控制台意外宕机时，ODP 依然能够正常访问已访问过的集群，但无法访问尚未访问过的集群。启动时基于 RootService 列表时，ODP 只能访问固定的单个集群，独立于 OCP。如果本地服务器发生故障，服务器负载均衡器（SLB）会自动检测故障并进行流量切换，ODP 无需执行额外操作。

独立部署

在独立部署模式下，ODP 作为独立组件部署在专属服务器上（可与 OBServer 节点同机器，通常建议独立部署），实现计算与接入层的资源隔离。这种模式既支持以 OCP 方式启动（可访问多个集群），也支持基于 RootService 列表启动（固定访问单个集群，独立于 OCP）。

接入层高可用：负载均衡器 + OBProxy 集群

在生产环境中，OBProxy 的高可用并非依靠 OBProxy 本身，而是采用负载均衡器（LB）+ OBProxy 集群的经典架构。该架构通过引入负载均衡器将客户端请求分发到多个 OBProxy 实例，确保在任意一台 OBProxy 故障时业务无感知。

典型接入架构

构建接入层高可用的标准模式如下：

• 集群化部署：至少部署两个 OBProxy 实例形成集群，消除单点风险。
• 负载均衡器：在 OBProxy 集群前端部署四层或七层负载均衡器（如 F5、SLB、NLB、HAProxy、Nginx 等），将客户端请求分发至集群中健康的实例。
• 高可用客户端：业务应用程序通过负载均衡器的 VIP（虚拟 IP）地址或域名连接数据库，而非直接连接单个 OBProxy IP，从而实现故障自动切换。

-- 高可用架构下的连接串示例（通过 SLB VIP 访问）
        jdbc:mysql://10.0.0.100:2883/test?user=root@tenant_name&password=****

OBProxy 集群的常用管理方式

通过 OceanBase Cloud Platform（OCP）可以高效管理 OBProxy 集群的全生命周期。登录 OCP 控制台后，在左侧导航栏点击 OBProxy 即可进入管理页面，在页面上方点击"创建 OBProxy 集群"按钮开始配置。创建过程中需指定集群名称、proxyro 用户密码（用于 ODP 访问 OceanBase 集群的专用账号）以及 ODP 软件包的版本。此外，OCP 还提供接管外部 OBProxy、删除/重启/升级 OBProxy 节点、向集群中添加新 OBProxy 等丰富的管理功能。

故障检测与自动容灾处理

OBProxy 通过多层次的主动检测机制，及时发现 OBServer 节点的状态变化，并自动采取流量切换和故障隔离措施，确保服务持续可用。

故障检测

• 后端节点状态刷新：通过调度任务定期刷新 OBServer 节点、Zone 以及主备集群的状态。OBProxy 还实现了服务端持久连接和 KeepAlive 机制，主动探测与后端 OBServer 的连接状况，帮助识别 idle 连接被异常关闭等场景。
• 客户端 KeepAlive 探活：通过客户端 KeepAlive 机制探测 OBProxy 与客户端连接的状况，同时可以避免 SLB 等负载均衡的空闲超时。

黑名单机制

OBProxy 使用黑名单机制实现后端 OBServer 的自适应访问控制。该机制在 OBServer 错峰合并、升级、Leader 切换、宕机、启动和停止等过程中，引导流量避开故障节点。

• 宕机黑名单：一旦检测到某台 OBServer 宕机或因执行 stop server 命令暂停服务，该节点会被加入宕机黑名单。此时应用不再访问该节点，直到该节点恢复正常后才会从黑名单中释放。
• 活着不可用黑名单：与宕机黑名单不同，活着不可用黑名单中 OBServer 的状态是暂时的或不确定的（如资源限制、内存超限、正在合并）。此类节点会周期性重试，一旦恢复正常即被放出黑名单。
• 优先级规则：宕机黑名单优先级高于活着不可用黑名单。

核心配置参数

通过 SHOW PROXYCONFIG 和 ALTER PROXYCONFIG SET 命令可查看和修改 OBProxy 的配置参数。与黑名单相关的核心参数如下：

请求级故障处理

• 处理中的请求：OBProxy 实现了异步中止机制。当检测到 OBServer 节点故障后，主动中止正在处理的连接请求，避免长时间等待导致业务连接池耗尽。
• 新请求处理：利用黑名单机制，避免将新的请求发送到已故障的节点。
• 副本位置感知：当 OBServer 节点因故障发生副本切换时，该节点会主动通知 ODP 路由信息的变化。ODP 据此感知副本的新位置，将后续请求路由到新副本。但如果 OBServer 节点完全不可响应，ODP 则需依赖探测机制发现异常，此时副本位置信息的更新可能会有延迟。

-- 查看 OBProxy 配置（需通过 root@proxysys 账号连接 2883 端口）
        SHOW PROXYCONFIG;

        -- 修改配置参数
        ALTER PROXYCONFIG SET congestion_failure_threshold = 3;

        -- 查看 OBProxy 集群中的实例信息
        SHOW PROXYINFO;

主备集群架构下的容灾支持

OBProxy 支持两地两中心的物理备库（Physical Standby Database）解决方案。当主集群发生变化时，OBProxy 能够高效地切换至新的主集群，实现跨数据中心的高可用容灾能力。RTO 取决于 OBServer 节点的检测时间和状态刷新任务的调度间隔，默认检测间隔为 20 秒。此外，OBProxy 也支持配置弱一致性读策略（通过 obproxy_read_consistency 参数），将部分读流量转发至 Follower 副本，进一步实现读写分离并分摊主副本负载。

OBProxy 作为 OceanBase 集群的统一接入层，其核心配置参数直接影响着系统的性能、稳定性和高可用能力。本章基于 OceanBase 4.x 版本的最新特性，系统梳理 OBProxy 的核心配置参数体系，提供生产环境的最佳实践配置建议，并介绍常见问题定位与优化策略，帮助 DBA 高效完成 OBProxy 的配置与运维。

-- 查看 OBProxy 的所有配置参数
        SHOW PROXYCONFIG;

        -- 查看特定配置项（使用 LIKE 模糊匹配）
        SHOW PROXYCONFIG LIKE 'work_thread_num';

        -- 修改配置参数（部分可动态生效）
        ALTER PROXYCONFIG SET work_thread_num = 64;

        -- 修改需要重启 OBProxy 才能生效的参数
        -- 应在修改参数后重启 OBProxy 进程

一、CPU 与线程配置

核心线程参数说明

二、内存配置

核心内存参数说明

三、连接与超时配置

核心连接参数说明

四、路由策略配置

OBProxy 提供丰富的路由功能，用户可根据业务场景设置对应的配置项来控制路由策略，实现最佳路由效果。

核心路由参数说明

五、日志与监控配置

核心日志参数说明

-- 查看 OBProxy 的内存使用情况
        SHOW PROXYMEMORY;

        -- 查看 LDC 部署情况（需配置 proxy_idc_name）
        SHOW PROXYINFO IDC;

        -- 查看内部路由表状态（table entry）
        SHOW PROXYROUTE;

        -- 查看 OBProxy 配置（特定项）
        SHOW PROXYCONFIG LIKE 'proxy_idc_name';

六、TCP KeepAlive 与探活配置

配置合理的 TCP KeepAlive 参数可以有效避免因网络设备空闲超时而意外中断连接。

服务端探活配置（OBProxy → OBServer）

七、生产上线前检查清单

• 端口冲突扫描：ss -lntp | grep -E '288[1-4]'，确认无其他进程抢占 OBProxy 的关键端口（2883/2884）。
• IPv6 双栈验证（若开启）：同时使用 IPv4 和 IPv6 的 obclient 连接并执行 SELECT 1;，确保返回一致。
• 连接风暴压测：使用 sysbench 或自研脚本模拟 5k 并发短连接，观察 OBProxy 是否出现 accept queue dropped（ss -s 查看）。若出现，需调大 backlog 并检查 ulimit -n 是否 ≥65535。
• 高可用验证：部署至少 2～3 个 OBProxy 实例，并使用负载均衡器（F5/SLB/HAProxy）提供统一 VIP，测试任意一台 OBProxy 故障时业务是否无感知切换。
• 配置备份与版本管理：将 OBProxy 的配置文件（obproxy_config.yaml / obproxy.conf）纳入版本管理，便于追踪变更和快速回滚。

OBProxy（ODP）作为 OceanBase 集群的统一接入层，其配置和部署状态直接影响业务的稳定性和高可用能力。本章基于 OceanBase 4.x 版本的官方推荐，结合生产环境的实践经验，系统梳理 OBProxy 上线前的完整检查清单，帮助 DBA 在业务流量接入前完成全面验证，避免上线后出现性能瓶颈或可用性风险。

一、环境与软件版本检查

在部署 OBProxy 之前，需要确认服务器软硬件环境满足要求，并选择合适的 OBProxy 版本。

• 硬件资源：ODP 服务器推荐配置为 4 核 CPU、8 GB 内存、200 GB 磁盘，可使用 OBServer 节点作为 ODP 部署服务器。ODP 启动后常驻 CPU 占用约 0.7 核，内存约 100 MB，但峰值负载时仍需预留充足资源。
• 操作系统：建议使用 CentOS 7.x 及以上版本，内核版本不低于 3.10。务必确认服务器防火墙已开放 ODP 所需的端口：2883（业务端口）、2884（Prometheus 端口）、2885（内部通信端口）。
• 版本选型：OBProxy 必须与 OceanBase 集群的版本系列匹配，V4.x 集群必须使用 ODP V4.0.0 及以上版本。建议使用 GitHub Releases 中最新稳定版本，生产环境需关注每个版本的功能迭代和缺陷修复情况。
• obdiag 自动检查：执行 obdiag check run --obproxy_cases=proxy 可自动检查 OBProxy 版本是否为不建议使用的缺陷版本（version.bad_version）或已不再支持的旧版本（version.old_version）。

二、部署与配置检查

完成 ODP 部署后，需验证其配置是否与生产预期一致，并确认与 OceanBase 集群的连通性。

• 部署方式验证：确认 ODP 已正确接入 OceanBase 集群。使用 OCP 部署时，可在 OCP 控制台查看 OBProxy 集群列表，确认 ODP 实例状态正常。通过 obd 部署时，确保配置文件中的 rs_list 或 OceanBase 集群信息正确。
• 配置参数检查：使用 root@proxysys 账号登录 ODP（默认 2883 端口），执行 SHOW PROXYCONFIG; 查看当前配置，重点关注以下核心参数：
  • listen_port：业务监听端口，默认为 2883。
  • prometheus_listen_port：Prometheus 指标拉取端口，默认为 2884，应与业务端口分离。
  • proxy_mem_limited：进程内存上限，OCP 部署默认为 2 GB，命令行安装未指定时为 800 MB，生产环境建议调整为 4 GB～8 GB。
  • client_max_connections：最大客户端连接数，默认为 8192。
• 热参数动态验证：部分配置（如 proxy_mem_limited）修改后可动态生效（need_reboot = false），修改后无需重启。建议在上线前确认所有需要重启的参数均已按需配置。
• 连通性测试：使用 MySQL 或 OBClient 客户端通过 ODP 的 IP 和端口（如 mysql -h 10.10.10.1 -P 2883 -u root@tenant_name -p）登录目标租户，并执行 SELECT 1; 验证数据链路畅通。

三、高可用与负载均衡验证

生产环境必须确保接入层的高可用能力，避免单个 ODP 实例故障导致业务中断。

• 多实例部署：建议至少部署 2～3 个 ODP 实例，避免单点故障。可使用 obd 或 OCP 向集群中添加多个 ODP 节点。
• 负载均衡器配置：在 ODP 集群前端部署 SLB/F5/HAProxy 等负载均衡器，配置健康检查，将客户端请求分发至健康 ODP 实例。应用程序通过负载均衡器的 VIP 或域名访问数据库，而非直连单 ODP IP。
• 高可用模拟测试：通过 kill -9 或 kill -19 模拟 ODP 进程异常退出，通过 kill -18 模拟进程暂停，观察负载均衡器是否能自动将流量切到健康 ODP，业务侧是否出现明显抖动。
• 守护进程验证：确认 ODP 安装目录下的 obproxyd.sh 守护进程已正确运行，其通过 nc 命令周期性探测监听端口（默认 2883）。若检测到 ODP 进程不存在，守护进程会立即拉起 ODP，恢复时间约 1 秒。
• 主机故障模拟：在业务压测期间，对部署 ODP 的服务器模拟网络中断或关机，验证 RTO 是否满足业务 SLA 要求。

四、性能压测与容量评估

通过压测验证 ODP 在当前硬件配置下的性能上限，确保其不会成为系统的瓶颈。

• ODP 独占 QPS 基线：在独占场景下，单 ODP 实例的 QPS 通常在 2 万～3.5 万 之间，具体取决于 CPU 型号和配置。
• 水平扩展策略：如果 QPS 不满足业务需求，可以通过水平扩容（增加 ODP 实例数量）线性提升集群整体吞吐量。若无法扩容，可单独优化单实例性能。
• 吞吐量指标：重点关注 ODP 实例的 CPU 使用率（top -H -p pidof obproxy）和网络带宽占用。若某个 ODP 实例的 CPU 接近打满，说明已达性能上限，需增加实例或提升硬件配置。
• 延迟指标：检查 ODP 内部处理耗时（slow_proxy_process_time_threshold），该值通常在 μs（微秒）级。如果出现异常延迟，需排查网络链路或后端 OBServer 响应时间。
• 资源规格评估：根据预估的 QPS 峰值，提前规划 ODP 实例数量和配置。若 CPU 资源充足但 QPS 偏低，需进一步定位组件瓶颈（网络、磁盘 I/O、内存等）。

五、安全与访问控制检查

确保 ODP 和 OceanBase 集群的网络安全策略已正确配置，防止未授权访问。

• 租户白名单：在 OceanBase 租户侧配置 ob_tcp_invited_nodes，限制仅允许 ODP 的 IP 地址或业务应用的 IP 段访问租户。
• 网络安全组/防火墙：确认服务器防火墙只开放 ODP 所需的 2883、2884 端口，对 2885 等内部端口进行白名单限制。生产环境建议将 ODP 与管理网络隔离，限制 root@proxysys 账号的访问来源。
• 账号权限管理：严格管理 root@proxysys 的密码，避免泄露。业务应用应使用普通租户账号（用户名@租户名）连接 ODP。
• 访问日志审计：开启 ODP 的审计日志功能，定期分析异常访问模式，及时发现潜在安全风险。

六、监控与告警配置

在上线前完成监控和告警的配置，以便业务接入后实时掌握 ODP 的运行状态。

• OCP 监控大盘：在 OCP 控制台中查看 ODP 的关键指标，包括 QPS、连接数、内存使用率、慢查询数量等。
• Prometheus 集成：确认 enable_prometheus = true，并验证 http://odp_ip:2884/metrics 是否可正常拉取指标数据。
• 告警规则配置：设置合理的告警阈值，重点关注以下指标：
  • ODP 进程内存使用超过 proxy_mem_limited 的 90%，此时 ODP 会在日志中打印 obproxy's memory is out of limit's 90%。
  • SQL 执行失败次数（sql_execute_failed_count）突增。
  • ODP 与 OBServer 的连接异常或频繁断开。

七、obdiag 自动巡检检查

使用 OceanBase 官方提供的敏捷诊断工具 obdiag 对 OBProxy 进行一键巡检，高效发现配置和潜在风险。

• 安装 obdiag：在管理节点上安装 obdiag，建议使用最新版本。
• 执行巡检命令：

  # 对 OBProxy 执行专项巡检（检查版本、参数配置等）
          obdiag check run --obproxy_cases=proxy
  
          # 对 OceanBase 数据库执行全量巡检（含 OBProxy）
          obdiag check run
  
          # 指定报告输出格式（HTML/JSON/XML/YAML/TABLE）
          obdiag check run --report_type=html --store_dir=./check_report

• 巡检结果解读：巡检报告会包含每个检查项的详细结果和运维建议，重点关注 “WARNING” 和 “ERROR” 级别的异常项。例如：
  • version.bad_version：提示当前 OBProxy 版本存在缺陷，建议立即升级。
  • parameter.work_thread_num：检查工作线程数配置，防止线程耗尽问题。
  • parameter.enable_ob_protocol_v2_with_client：若已启用则告警。
• 部署环境检查：obdiag check run --cases=build_before 可在部署前对服务器环境进行预检，检查内核参数、docker0 网络接口等潜在问题。

八、上线检查清单汇总（Checklist）

上线前，建议按照以下清单逐项确认，确保 OBProxy 部署稳定可靠：

从 OceanBase V4.3.0 版本开始，新增了 租户克隆 功能。通过该功能，您可以在系统租户中基于一个源租户，快速克隆出一个全新的、数据与资源相互隔离的新租户。新租户在初始时刻包含的数据，就是源租户在执行克隆语句那个时刻的一个快照。与传统的主备租户（基于日志同步）和复制租户（仅复制配置信息）不同，租户克隆是一种 基于快照和共享存储 的快速创建机制，因此具备极高的效率。

技术原理解析

租户克隆能实现“秒级”快速创建，其核心原理在于：创建时仅复制元数据，不复制用户数据，数据存放在共享存储上。初始化数据由源租户和新租户共享物理宏块实现。随着数据分别写入两个租户，共享的宏块会逐渐减少，独占宏块会逐渐增多。

六种核心应用场景

基于租户克隆的高效、隔离特性，它可以在以下六大场景中发挥关键价值。

1. 报表任务：当核心业务租户处于负载高峰期时，可以快速克隆一个专门用于跑报表的租户，避免复杂的报表查询拖慢核心业务。
2. 快弹只读备租户：利用克隆功能创建一个新租户并将其转换为一个只读备租户，主动从生产租户拉取日志，以准实时的方式分摊内部运营等复杂查询负载。
3. 应用版本发布：在版本发布前，克隆一个源租户作为验证环境。若新版本出现问题，可以快速丢弃克隆租户，保障源租户安全。
4. 数据库变更验证：在需要执行 DDL 等高风险变更操作前，先在克隆租户上模拟测试，验证其影响和可行性，有效降低变更风险。
5. 开发测试环境搭建：利用租户克隆，可以在短时间内为开发或测试人员准备一个与生产数据一致的隔离环境，提升开发测试效率。
6. 快速数据导出：需要对大量数据进行导出或处理时，克隆出一个新租户，在克隆租户上执行导出操作，既能减轻生产租户的负担，也能保护数据的安全。

架构版本限制与历史记录查询

• 最低版本要求：克隆源租户必须是 OceanBase V4.3.0 或更高版本的租户，不支持对 V4.3.0 之前版本的租户进行克隆。
• 克隆任务历史查询：从 V4.3.0 版本开始，您可以通过查询 DBA_OB_CLONE_HISTORY 视图来获取所有已完成的克隆任务记录，进行审计与排查。

租户克隆功能在提供高效、灵活的克隆能力的同时，也存在一系列重要的使用限制。深刻理解这些限制，是确保克隆操作顺利执行并维护系统稳定性的前提。本章将这些限制分为技术前提、系统环境限制、任务并发冲突和执行中禁止操作四类，并针对每一类提供相应的状态检查方法，供 DBA 在克隆前进行自动化排查。

一、技术前提

• 源租户版本要求：克隆源租户必须是 OceanBase 数据库 V4.3.0 或更高版本 的租户。不支持对 V4.3.0 之前版本的租户执行克隆租户的操作。
• 日志归档必须开启：租户克隆功能强依赖于租户的日志归档功能。在执行租户克隆操作前，必须确保源租户已开启日志归档模式，并且在租户克隆过程中，源租户不能关闭日志归档模式。为租户开启归档模式后，如果希望立即执行克隆租户的操作，需要执行 ALTER SYSTEM MINOR FREEZE TENANT = tenant_name; 语句对该租户发起一轮转储。
• 克隆源必须为主租户：不支持对备租户（Standby Tenant）执行克隆租户的操作。您只能克隆 OceanBase 集群中的主租户（Primary Tenant）。

-- 检查租户版本（需 ≥ V4.3.0）
        SELECT TENANT_ID, TENANT_NAME, VERSION FROM oceanbase.DBA_OB_TENANTS;

        -- 检查租户日志归档状态（需确认归档已开启且路径正确）
        SHOW PARAMETERS LIKE 'log_archive_dest';

        -- 检查租户是否为主租户（role=PRIMARY）
        SELECT TENANT_ID, TENANT_NAME, ROLE FROM oceanbase.DBA_OB_TENANTS;

二、系统环境限制

• Unit 所在 OBServer 节点必须可用：当源租户中有 Unit 所在的 OBServer 节点不可用时，不支持执行租户克隆的操作。
• 无正在进行的升级任务：不允许在数据库或租户升级过程中执行克隆租户的操作。
• 日志流无容灾任务：不允许在日志流副本有容灾任务时执行克隆租户的操作。确认方法：系统租户通过指定当前租户的 tenant_id 查询 CDB_OB_LS_REPLICA_TASKS 视图，如果查询结果为非空，则表示该租户有容灾任务正在执行；用户租户可通过查询 DBA_OB_LS_REPLICA_TASKS 进行确认。

-- 检查 Unit 所在的 OBServer 节点是否可用
        SELECT UNIT_ID, TENANT_ID, SVR_IP, STATUS FROM oceanbase.GV$OB_UNITS;

        -- 检查是否存在容灾任务
        SELECT * FROM oceanbase.CDB_OB_LS_REPLICA_TASKS WHERE tenant_id = xxx;
        SELECT * FROM oceanbase.DBA_OB_LS_REPLICA_TASKS;

三、任务并发冲突

在执行租户克隆操作前，必须确保源租户上没有以下正在执行的变更任务：

• Switchover：不允许在 Switchover（无损切换）过程中执行克隆租户的操作。
• 日志流（LS）变更：不允许在增加 LS、删除 LS 或 LS 属性变化的过程中执行克隆租户的操作。
• Transfer：不允许在 Transfer（分区转移）过程中执行克隆租户的操作。
• Unit 迁移：不允许在 Unit 迁移过程中执行克隆租户的操作。
• 租户缩容：在通过减少资源池中的 UNIT_NUM 个数来对租户进行缩容时，不允许执行克隆租户的操作。

-- 检查是否存在 Transfer 任务（CDB_OB_BALANCE_JOBS）
        SELECT * FROM oceanbase.CDB_OB_BALANCE_JOBS WHERE tenant_id = xxx;

        -- 检查是否存在 Unit 迁移任务
        SELECT * FROM oceanbase.DBA_OB_UNITS WHERE MIGRATE_FROM_SVR_PORT IS NOT NULL;

四、克隆任务执行期间禁止的操作

在租户克隆任务执行过程中，不能对源租户进行以下操作。如果需要执行，必须先取消当前正在进行的克隆任务。

• 对源租户执行 Switchover 操作；
• 通过修改源租户的 UNIT_NUM 个数或 PRIMARY_ZONE 第一优先级进行租户扩缩容操作；
• 对源租户执行增加副本、减少副本、调整副本分布等操作；
• 对源租户手动执行 Transfer 操作；
• 对源租户手动执行 Unit 迁移操作；
• 对源租户执行升级操作。

如果必须执行上述操作，您可以取消克隆任务后再执行，取消克隆任务的详细操作可参考官方文档。

-- 查看正在执行的克隆任务进度
        SELECT * FROM oceanbase.DBA_OB_CLONE_PROGRESS\G

        -- 查看已完成的克隆任务历史
        SELECT * FROM oceanbase.DBA_OB_CLONE_HISTORY\G

租户克隆功能在实现“秒级”快速创建的同时，其共享存储的机制也带来了一个必须重点关注的问题：存储空间随时间自然膨胀。本章深入剖析克隆租户存储空间变化的内在规律，提供全方位的监控、评估与优化策略，帮助 DBA 有效管理克隆租户的存储成本，避免因空间不足引发系统异常。

一、存储空间膨胀原理详解

租户克隆借鉴了类似操作系统“进程 fork”的设计理念。在克隆时，只拷贝源租户的元数据（表结构、索引定义等），物理数据块则以只读方式共享，正是这种“Copy-on-Write”机制赋予了克隆秒级完成的极高效率。克隆过程中，将源租户的元数据拷贝一份给到新克隆租户，使得新克隆租户在初始时刻访问的是和源租户完全相同的物理宏块。[reference:15]

• 初始共享阶段：克隆刚完成时，所有物理数据块均为共享状态，几乎不产生额外的存储开销。
• 分岔点：当源租户或克隆租户首次修改某个共享数据页时，系统会为该数据页创建一个独立的副本，这一过程被称为“写时复制”。修改方将基于这个新副本进行后续操作。此后，该数据页在源租户和克隆租户中分别独立，不再共享，占用双份存储空间。
• 膨胀累积：克隆租户使用时间越长、写入或更新的数据越多，需要单独占用的物理宏块就越多，存储空间的占用也随之逐步增加，需要及时关注 OBServer 节点上存储空间的占用情况。[reference:16]

二、存储空间监控与用量评估

准确评估克隆租户的存储成本，是进行成本核算和资源规划的关键。OceanBase 提供了以下核心视图和方法。

1. 租户数据空间监控

• GV$OB_UNITS：通过该视图中的 DATA_DISK_IN_USE 和 LOG_DISK_IN_USE 字段，可直接查看每个 Unit 当前使用的数据磁盘和日志磁盘大小。[reference:17]同时可通过 MEMORY_SIZE 和 LOG_DISK_SIZE 字段获得该 Unit 的内存和日志磁盘规格上限，帮助判断资源是否充足。
• CDB_OB_TABLET_REPLICAS / DBA_OB_TABLET_REPLICAS：查看各租户 Tablet 副本的物理存储详情，可用于分析空间占用的明细分布。

-- 查询集群中各节点、各租户 Unit 的实际存储占用（系统租户下执行）
        SELECT TENANT_ID, SVR_IP, DATA_DISK_IN_USE / 1024 / 1024 / 1024 AS data_disk_used_gb,
            LOG_DISK_IN_USE / 1024 / 1024 / 1024 AS log_disk_used_gb,
            MEMORY_SIZE / 1024 / 1024 / 1024 AS memory_limit_gb,
            LOG_DISK_SIZE / 1024 / 1024 / 1024 AS log_disk_limit_gb,
            STATUS
        FROM oceanbase.GV$OB_UNITS
        WHERE TENANT_ID = 1002;   -- 替换为实际租户 ID

        -- 查看集群中所有租户 Unit 的资源规格和状态
        SELECT UNIT_ID, TENANT_ID, STATUS, MAX_CPU, MEMORY_SIZE, MAX_IOPS, LOG_DISK_SIZE
        FROM oceanbase.DBA_OB_UNITS;

2. 会话级内存监控

若克隆租户主要用于分析查询，其 SQL 执行期间可能消耗大量工作区内存。可通过 GV$OB_SQL_AUDIT 的 WORK_AREA_MEMORY_USED 列定位大内存消耗的 SQL，结合资源组做好资源隔离。

3. 利用 OCP 进行可视化监控

通过 OceanBase Cloud Platform（OCP）平台进入具体的租户概览页面，可以直观地查看数据盘和日志盘的使用趋势。此外，OCP 还支持对部署在 Kubernetes 上的 OBProxy 进行白屏化创建和管理。

三、存储空间回收与优化策略

1. 执行 Major Compaction

在执行大量的 DML 操作（尤其是 DELETE 和 UPDATE）后，存储空间可能存在“空洞”。合并可以对数据进行重新整理，清理过期的多版本数据，有效回收存储空间，提高存储效率。在克隆租户使用一段时间后，建议根据其数据变化量，定期执行合并操作。

-- 手动触发租户级合并（系统租户下执行）
        ALTER SYSTEM MAJOR FREEZE TENANT = clone_tenant_name;

        -- 查看合并任务进度（包含合并状态和 GLOBAL_BROADCAST_SCN 等详细信息）
        SELECT * FROM oceanbase.DBA_OB_MAJOR_COMPACTION;

2. 定期清理过期克隆租户

删除不再使用的克隆租户是释放存储空间最直接有效的方式。DBA 应建立克隆租户的全生命周期管理策略，设计合理的过期清理机制，定期扫描并删除超过保留期限的克隆租户。删除租户时，系统会自动回收其占用的元数据和用户数据空间。此外，删除大租户可能触发大量的磁盘操作，导致系统瞬时 IO 负载增加，建议在业务低峰期执行。

3. 合理规划克隆租户的资源规格

在创建克隆租户时，应进行充分的容量评估。不同于源租户，克隆租户通常用于临时或特定场景（如报表、验证），其资源需求可能更低。在克隆命令中，可以为其指定更小的 MAX_CPU、MEMORY_SIZE 和 MAX_IOPS，以实现更精细的成本控制。但是，Unit 数量及 Unit 在各个 OBServer 节点上的分布，均与源租户保持一致。[reference:18]

-- 在克隆租户时为其指定一个新的、更小的 Unit Config
        CREATE RESOURCE UNIT small_unit 
            MAX_CPU=4, MIN_CPU=4, 
            MEMORY_SIZE='16G', 
            MAX_IOPS=64000, MIN_IOPS=64000;

        CREATE TENANT clone_tenant FROM source_tenant 
            WITH RESOURCE_POOL clone_pool, UNIT small_unit;

OceanBase 数据库从 V2.x.x 版本开始正式支持 Oracle 兼容模式（即 Oracle 租户），旨在为从 Oracle 数据库迁移至 OceanBase 的业务系统降低改造成本，同时也让数据库设计开发人员、数据库管理员等能够复用积累的 Oracle 技术知识，快速上手 OceanBase 数据库。经过多个大版本的持续演进，Oracle 兼容模式已成为 OceanBase 的关键功能之一。

OceanBase 4.x 系列版本关键里程碑

兼容性的持续增强是 OceanBase 4.x 系列版本的核心演进方向，以下为几个关键的里程碑版本：

• V4.1.0：Oracle 模式兼容性基础版本，提供较完善的数据类型、SQL 语法、内置函数和系统视图兼容，已适配多种 Oracle 密码策略，支持用户锁定和解锁功能，并开放 OMS 迁移能力。
• V4.2.0：增加 Auto DOP（自动并行度）功能，支持并行查询智能化调度，同时引入 SPM（SQL Plan Management），大幅提升复杂查询场景的计划稳定性与性能。
• V4.2.1 LTS：Oracle 兼容性的里程碑版本，是首个 Oracle 兼容模式推荐长期支持（LTS）版本。它汇集了 OceanBase 在银行、证券、保险、运营商、电力、人社等多个行业实际业务场景中打磨出的各项兼容能力，可让更多业务场景平滑地完成应用迁移。
• V4.3.0：正式支持列存引擎与物化视图，并引入向量化执行引擎 2.0，全面加速 AP 分析负载。
• V4.3.3：正式支持向量检索（ANN）能力，支持向量数据类型和向量索引，同时新增列存副本功能，为 HTAP 混合负载下的性能隔离提供更优方案。
• V4.3.5：OLAP 能力进一步强化，包括基于物化视图的查询改写、物化视图实时更新、旁路导入等，大幅增强复杂分析场景的易用性与实时性。

更多功能变动信息，建议参考对应版本的官方文档。

数据类型兼容

OceanBase 数据库兼容大部分 Oracle 数据库中支持的数据类型。Oracle 数据库中有 24 种数据类型，OceanBase 数据库目前支持其中的 20 种。基于优化考虑，LONG 和 LONG RAW 数据类型已过于陈旧，OceanBase 暂不计划支持；BFILE 和 NCLOB 目前也尚未兼容。对于大对象（LOB）数据类型，OceanBase 支持 BLOB 和 CLOB，存储上限为 48 MB。

-- 查看当前租户的字符集（Oracle 模式）
        SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

系统视图兼容

OceanBase 已兼容 Oracle 大量的字典视图（Data Dictionary Views）与性能视图（Performance Views）。其中，字典视图已兼容大量（如 ALL_*、DBA_*、USER_* 三类权限视角），为日常运维和性能诊断提供了完整的兼容视图生态。

-- 在 Oracle 租户中可直接查询兼容的系统视图
        SELECT * FROM ALL_TABLES WHERE OWNER = 'SCHEMA_NAME';
        SELECT * FROM DBA_OB_TABLET_REPLICAS;

PL 全面兼容（Oracle 模式）

OceanBase 已经基本能够兼容 Oracle 全部的研发功能。已支持的 PL 语法及功能涵盖数据类型、流程控制、集合与记录（多维集合暂不支持）、静态/动态 SQL 语句、子程序与包、触发器、异常处理、系统包（如 DBMS_LOB、DBMS_OUTPUT、DBMS_SQL 等）以及自定义数据类型等多个核心维度。这极大降低了将大规模 PL/SQL 迁移至 OceanBase 数据库的难度与成本。

-- Oracle 模式示例：创建存储过程
        CREATE OR REPLACE PROCEDURE example_proc (p_id IN NUMBER, p_name OUT VARCHAR2) IS
        BEGIN
            SELECT name INTO p_name FROM users WHERE id = p_id;
        EXCEPTION
            WHEN NO_DATA_FOUND THEN
                p_name := NULL;
        END example_proc;
        /

备份恢复与安全特性

兼容 Oracle 模式的多数备份恢复与安全特性，包括租户级物理备份、日志归档、PITR（基于时间点的即时恢复）以及备份数据自动过期清理，保证企业级数据安全与合规需求。安全特性方面，支持与 Oracle 高度一致的密码策略（密码生命周期、密码复杂度、密码重用限制等），同时支持 TDE 透明加密、SSL 链路加密与基于标签的安全（Label Security）机制。

OceanBase 数据库在数据类型、SQL 语法、PL 对象等基础功能上与 Oracle 数据库高度兼容，但受限于底层分布式架构和产品形态的差异，部分 Oracle 原生特性暂不支持或存在行为差异。本章系统梳理 Oracle 迁移至 OceanBase（Oracle 模式）过程中的主要不兼容特性，并提供详细的迁移注意事项和最佳实践指南，帮助 DBA 在迁移前有效规避风险，确保迁移过程平稳顺畅。

一、数据类型不兼容

不兼容的数据类型

Oracle 原生支持 24 种数据类型，OceanBase 目前支持其中的 20 种。以下为暂不兼容的数据类型：

大对象（LOB）数据类型限制

OceanBase 支持 BLOB 和 CLOB 类型，但存储上限为 48 MB（Oracle 可达 4 GB），且在大数据量场景下性能可能不如预期，建议复杂场景中尽量避免使用或改用普通表存储。迁移时需注意检查源端 LOB 字段最大值，防止数据丢失。

字符集注意事项

Oracle 模式租户创建时，字符集由租户属性决定。建议在创建租户前与源端对齐字符集，避免迁移后出现字符乱码问题。

二、SQL 语法不兼容

DDL 语法差异

在 Oracle 迁移至 OceanBase 的过程中，部分 DDL 语法存在不兼容或行为差异，尤其在约束、索引和分区定义方面。

1. 约束类（Constraint）

• 不支持 references_clause 子句定义外键：外键关联的 REFERENCES 子句会被忽略。
• 不支持 constraint_state 约束状态属性：如 DEFERRABLE、INITIALLY DEFERRED/IMMEDIATE 等属性会被忽略。
• 不支持 ENABLE/DISABLE 约束状态：相关约束控制子句不兼容。

2. 索引类（Index）

• 不支持 bitmap_join_index_clause 子句定义位图索引：位图连接索引定义会报错，系统会忽略 BITMAP 关键字，创建普通索引而非位图索引。
• 全局索引分区定义部分属性被忽略：同步 DDL 中包含 index_partitioning_clause 中的 segment_attributes_clause（如 TABLESPACE 子句）会被忽略。

3. 表分区（Table Partition）

• 不支持 set_subpartition_template 子句：为每个表分区创建默认 RANGE/LIST/HASH 子分区的子句不兼容，会报错。
• 不支持 exchange_partition_subpart 子句：交换数据和索引 segment 的分区操作不兼容。
• 不支持 enable_disable_other_clause 子句：启用/禁用表锁或触发器的 DDL 控制子句不兼容，会报错。

物化视图刷新模式差异

OceanBase 支持创建物化视图和物化视图日志，但 不支持 ON COMMIT 或 ON STATEMENT 刷新模式，这两种实时刷新语法不兼容。

数据类型变更限制

OceanBase 与 Oracle 在修改列数据类型时的限制存在差异。使用 ALTER TABLE ... MODIFY 修改带约束（如主键、唯一键、CHECK）的列时，目标类型的兼容范围与 Oracle 不同，迁移前需详细对照目标类型映射表。

支持的分区操作说明

OceanBase 在分区 DDL 方面支持新增、删除、清空、重命名等常用操作，但不支持 Oracle 的部分高级分区 DDL 语法（如 EXCHANGE PARTITION、MERGE PARTITIONS、SPLIT PARTITION），迁移时需改为手动重建分区表。

三、PL 与系统包不兼容

复杂嵌套类型不支持

OceanBase V4.x table 嵌套类型暂不支持复杂嵌套类型（如 table(collection(collection(record(basic type))))），仅支持简单嵌套类型 table(collection(record(basic type)))，迁移时建议采用多层 FOR LOOP 手动遍历。

外部 Java 调用不兼容

OceanBase 内核暂不支持调用外部 Java，迁移过程中若遇到 AS LANGUAGE JAVA NAME 声明，需重写 PL/SQL 逻辑以适配 OceanBase。

系统包能力差异

部分系统包如 UTL_FILE、DBMS_SCHEDULER 等高级功能在 OceanBase 中能力有限或行为存在差异，需在评估阶段重点排查。

四、性能与优化器差异

Oracle Hint 不完全适用

OceanBase 优化器采用基于代价（CBO）的优化模型，与 Oracle 优化器存在差异。Oracle 中的部分 Hint 在 OceanBase 中可能无效甚至报错，迁移时需逐一验证并删除无效的 Legacy Hint，必要时改用 OceanBase 支持的 Hint（如 /*+ PARALLEL(8) */、/*+ LEADING(...) */ 等）。

游标循环 + 单条 DML 是性能杀手

OceanBase 的强项在于分布式并行计算与批处理（Set-based）。“游标循环 + 单条 DML”在分布式架构下是绝对的性能瓶颈，迁移时应重写为批量操作（如 BULK COLLECT + FORALL），充分利用 OceanBase 的批处理能力。

索引类型差异：主键索引迁移注意事项

Oracle 上的主键默认是全局索引。使用 DBCAT 迁移到 OceanBase 时会变成本地索引，而使用 OMS 迁移则仍是全局索引。两者在性能表现上存在差异，迁移前需根据业务查询模式选择合适的索引类型。

五、迁移最佳实践与工具链

迁移评估工具链

• OMA（OceanBase Migration Assessment）：官方兼容性评估工具，提供精准的兼容性评估、性能评估和分布模式建议，输出详细的评估报告和改造建议。
• DBCAT：轻量级命令行工具，支持 Oracle 与 OceanBase 之间的 DDL 转换和 Schema 比对，适用于结构迁移和 Schema 验证。

数据迁移工具链

• OMS（OceanBase Migration Service）：官方一站式数据迁移服务，支持结构迁移、全量迁移和增量同步，提供多维度数据校验和反向回流能力，是 Oracle 迁移至 OceanBase 的首选工具。
• DataX：开源数据同步工具，适用于特定场景的异构数据迁移。

迁移流程建议

1. 兼容性评估：使用 OMA 完成完整的兼容性评估，生成评估报告，梳理不兼容对象清单。
2. 环境准备：创建 OceanBase Oracle 模式租户，对齐字符集，配置合适的资源规格。
3. 结构迁移：使用 DBCAT 或 OMS 完成 Schema 迁移，验证表结构、索引、约束的正确性。
4. 全量迁移：使用 OMS 完成全量数据迁移，关注大表和 LOB 字段的迁移性能，必要时分批迁移。
5. 增量同步：配置 OMS 增量同步链路，确保源端与目标端数据实时一致。
6. 业务验证：在目标端完成核心业务场景的功能验证和性能测试。
7. 反向回流：配置 OMS 反向链路，确保紧急回退能力。

常见问题快速定位

• LOB 数据迁移：Oracle 中 LOB 数据可能超过 48M，迁移后会导致数据丢失。迁移前需使用 DBMS_LOB.GETLENGTH 检查最大长度。
• 复杂嵌套类型错误（ORA-00600）：因 OceanBase 不支持复杂嵌套类型。
• 存储过程报错：检查是否使用了 AS LANGUAGE JAVA NAME 或复杂嵌套类型。
• 优化器性能差异：检查 Hint 是否无效，验证计划并修改 SQL。

OceanBase 数据库在 MySQL 模式和 Oracle 模式下提供了完善的错误码体系，覆盖 SQL 执行、事务处理、资源管理、系统内部等各个层面。当应用出现异常时，快速识别错误码及其含义是高效排查问题的关键。本章根据 OceanBase V4.5.0 官方错误码文档，整理了生产环境中最高频的错误码，并给出详细的排查思路和解决方法。

错误码分类概览

了解错误码的数值范围有助于快速定位问题所属领域：

ob_error：命令行错误码查询工具

OceanBase 自带了轻量级命令行工具 ob_error，可根据错误码快速查询错误含义和解决建议，无需翻阅文档。该工具在 OceanBase 安装包的 bin 目录下，通常在 /home/admin/oceanbase/bin/ob_error（也可能是 ob_error 在 PATH 中）。

基本用法

# 查询单个错误码
        ob_error <error_code>

        # 查询 OceanBase 内部错误码（带负号）
        ob_error -4012

        # 查询 MySQL 兼容错误码
        ob_error 1062

        # 查询 Oracle 模式错误码（支持 ORA- 前缀和 OBE- 前缀）
        ob_error ORA-00942
        ob_error OBE-00600

示例输出

$ ob_error -4012
        OceanBase Error:
            Code: 4012, SQLState: HY000, Cause: Timeout, query has reached the maximum query timeout: 10000000(us), maybe you can adjust the session variable ob_query_timeout or query_timeout hint, and try again.
            Solution: 1. Optimize SQL to reduce execution time. 2. Increase ob_query_timeout or ob_trx_timeout. 3. Check network latency or cluster load.

        $ ob_error 1045
        MySQL Compatible Error:
            Code: 1045, SQLState: 42000, Cause: Access denied for user '%.*s'@'%.*s' (using password: %s)
            Solution: Verify username/password, or grant the required privileges using GRANT statement.

集成到故障排查流程中

当您遇到未知错误码或需要快速获取解决思路时，优先使用 ob_error 工具查询，可大幅提升效率。同时结合 observer.log 中的详细堆栈和本章后续的错误码列表，形成“工具查码 → 日志定位 → 列表对照”的三步诊断法。

一、超时类错误

🔸 ERROR 4012 (HY000) : Timeout

现象：SQL 执行失败，返回 “Timeout, query has reached the maximum query timeout: ...”。
常见原因：

• 单条 SQL 执行时间超过了租户变量 ob_query_timeout 的值（默认 10,000,000 微秒 = 10 秒）。
• 事务总持续时间超过了 ob_trx_timeout（默认 86,400,000,000 微秒 = 24 小时）。
• RPC 请求超时或网络延迟过高。

排查步骤：

1. 首先判断是哪种超时：若错误信息中包含 “query timeout” 则是 SQL 超时；若包含 “transaction timeout” 则是事务超时。
2. 如果是 SQL 超时，通过 EXPLAIN 查看执行计划，检查是否存在全表扫描、缺失索引或分区裁剪失效等问题。
3. 如果是正常的大数据量操作（如报表、批处理），可适当调大超时参数：
   SET SESSION ob_query_timeout = 60000000; -- 调整为 60 秒
SET SESSION ob_trx_timeout = 86400000000; -- 24 小时（默认值已较大）
4. 若频繁出现且 SQL 本身很快，应排查网络或负载情况。

🔸 ERROR 6002 (25000) : Transaction idle timeout

现象：事务内两条 SQL 之间的间隔时间超过了 ob_trx_idle_timeout 阈值（默认 24 小时），系统自动回滚事务。
常见原因：应用程序在事务中进行了长时间的用户交互或业务逻辑处理，未及时提交或回滚。
解决方法：

• 回滚当前事务：ROLLBACK; 然后重新开始事务。
• 如果业务确实需要长时间空闲，可调大参数：SET SESSION ob_trx_idle_timeout = 172800000000; （48 小时）
• 检查应用代码，避免在事务中执行非数据库操作，尽量缩短事务生命周期。

🔸 ERROR 4038 (HY000) : The observer or zone is not the master

现象：请求发送到了 OBServer 的 Follower 副本，而不是当前 Leader 副本。
常见原因：Leader 切换后客户端 Location Cache 未及时更新，或 OBProxy 路由错误。
解决方法：

• OceanBase 内部会自动重试或重新获取路由，应用层通常无需处理。若频繁出现，检查集群是否存在频繁切主（网络分区、时钟不同步等）。
• 直连场景下，应通过 OBProxy 访问，避免直接连接 OBServer 节点。

二、资源与内存类错误

🔸 ERROR 4030 (HY000) : Over tenant memory limits

现象：租户整体内存使用量超过了上限，无法分配新内存。
常见原因：

• MemStore 写满（最常见）：写入压力大，转储速度跟不上。
• SQL 工作区（Work Area）内存占用过高，例如大型排序、Hash Join 等。
• KVCache（如 Block Cache、Row Cache）占用过高且无法及时淘汰。

排查与解决：

1. 查询 MemStore 使用情况：
   SELECT tenant_id, svr_ip, round(memstore_used/1024/1024/1024,2) used_gb, round(memstore_limit/1024/1024/1024,2) limit_gb, round(memstore_used/memstore_limit*100,2) pct FROM oceanbase.GV$OB_MEMSTORE WHERE tenant_id=1002;
2. 若 MemStore 占用过高且转储不及时，可手动触发转储：
   ALTER SYSTEM MINOR FREEZE TENANT = tenant_name;
3. 若 SQL 工作区占用高，可调整 ob_sql_work_area_percentage（默认 5%），或在 SQL 中使用 /*+ PARALLEL(8) */ 将部分计算下压。
4. 如果内存普遍紧张，需增加租户内存规格：
   ALTER RESOURCE UNIT unit_name MEMORY_SIZE = '32G';

🔸 ERROR 4013 (HY001) : No memory or reach tenant memory limit

现象：租户内存不足，但并非 MemStore 写满，而是其他模块（如 SQL 算子、Plan Cache 等）内存分配失败。
排查方法：查询内存详细分布：
SELECT tenant_id, svr_ip, ctx_name, round(hold/1024/1024/1024,2) hold_gb FROM oceanbase.GV$OB_MEMORY WHERE tenant_id=1002 ORDER BY hold DESC LIMIT 10;
定位到占用最高的 ctx_name，根据模块名称调整对应的参数（如 plan_cache_high_water_mark 或 large_query_worker_percentage）。

🔸 ERROR 5150 (HY000) : Tenant not in this server

现象：通过直连 IP 访问时，该 OBServer 节点上没有目标租户的资源单元（Unit）。
解决方法：

• 推荐使用 OBProxy 访问集群，OBProxy 会自动路由到正确的节点。
• 若必须直连，先查询租户 Unit 分布：SELECT * FROM oceanbase.GV$OB_UNITS WHERE TENANT_ID = xxx;，然后连接到对应的 SVR_IP 和端口。

🔸 ERROR 1040 (08004) : Too many connections

现象：客户端连接数超过了租户或 OBServer 设置的 max_connections 限制。
解决方法：

• 检查应用连接池配置，限制最大连接数，并确保连接池能正确回收闲置连接。
• 若确实需要更多连接，可调大参数：SET GLOBAL max_connections = 10000;（注意对应租户和 OBServer 资源配置）。
• 排查是否存在连接泄漏（例如应用程序未关闭连接）。

三、连接与通信类错误

🔸 ERROR 8001 (08004) : Server is initializing

现象：向正在启动的 OBServer 发送了请求。
解决方法：等待 OBServer 启动完成（通常几十秒到几分钟），无需其他操作。

🔸 ERROR 8002 (08004) : Server is stopping

现象：向正在关闭的 OBServer 发送了请求。
解决方法：等待 OBServer 正常退出，或若确需立即终止可执行 kill -9，但应确保业务已切走。

🔸 ERROR 8005 (08005) : Tenant id not match

现象：通过 OBProxy 连接时，租户名称发生了改变（如重命名），导致 OBProxy 缓存中的租户 ID 与新的不一致。
解决方法：断开当前连接，重新通过 OBProxy 建立连接即可。建议租户改名操作提前断开所有相关连接。

🔸 ERROR 2006 (HY000) : MySQL server has gone away

现象：客户端与 OceanBase 之间的连接被意外关闭。
常见原因：wait_timeout 或 interactive_timeout 导致连接空闲超时被服务端关闭；网络设备断开；服务端重启。
解决方法：在连接池中配置心跳检测（如 testOnBorrow、validationQuery），或适当调大 wait_timeout：SET GLOBAL wait_timeout = 28800;（8 小时）。

四、SQL 语法与对象类错误

🔸 ERROR 1062 (23000) : Duplicate entry for key

原因：违反唯一约束（主键或唯一索引），插入或更新的键值已存在。
解决：使用 INSERT IGNORE 忽略冲突，或 ON DUPLICATE KEY UPDATE 处理更新，或提前检查数据。

🔸 ERROR 1146 (42S02) : Table doesn't exist

原因：表名错误、数据库名错误、或当前租户下无该表。
解决：检查 SHOW TABLES; 确认表存在，注意大小写（取决于 lower_case_table_names 设置）。

🔸 ERROR 1045 (42000) : Access denied for user

原因：用户名、密码错误，或该用户无权限访问指定的数据库。
解决：确认用户名密码，检查 SHOW GRANTS FOR username@host;，使用 GRANT 授权。

🔸 ERROR 1054 (42S22) : Unknown column

原因：SQL 中引用的列不存在。
解决：检查列名拼写，或确认表结构是否发生过变更但 Schema 未刷新（可等待几秒重试）。

🔸 ERROR 1366 (HY000) : Incorrect string/integer value

原因：字段类型与插入值不匹配，例如向 INT 列插入了字符串。
解决：检查数据类型，使用 CAST 转换或修改插入值。

🔸 ERROR 1406 (22001) : Data too long for column

原因：插入的字符串长度超过列定义的最大长度。
解决：截断数据，或使用 ALTER TABLE MODIFY 扩大列长度。

🔸 ERROR 1235 (0A000) : %s not supported

原因：使用了当前 OceanBase 版本暂不支持的功能或语法（例如某些 Oracle 特有函数）。
解决：查阅对应版本的官方文档，使用支持的语法替代。

🔸 ERROR 4179 (HY000) : %s not allowed

原因：执行了与当前状态冲突的操作，例如在合并过程中修改租户 Locality，或在升级过程中执行 DDL。
解决：等待合并/升级等后台任务完成后再重试。

🔸 ERROR 4000 (HY000) : Common error

原因：通用内部错误，通常伴随更详细的错误信息。
解决：查看 observer.log 中对应时间的堆栈，联系技术支持或根据上下文自行分析。

🔸 ERROR 4664 (HY000) : Timeout OB_GET_LOCATION_TIME_OUT

原因：SQL 执行过程中获取分区位置信息超时。
解决：调大超时参数（ob_trx_timeout、ob_query_timeout），或检查网络延迟和集群负载。

🔸 ERROR 4209 (HY000) : partition has not leader

原因：分区没有 Leader 副本，常见于选举未完成或节点宕机。
解决：检查集群健康状态，等待选举完成；若长期无主，需排查网络或磁盘故障。

五、事务与锁类错误

🔸 ERROR 6005 (HY000) : Try lock row conflict

原因：并发事务更新同一行数据，加锁冲突。OceanBase 内部会自动重试，若重试仍失败则报此错误。
解决：检查应用是否存在热点行更新，考虑减少冲突（如使用乐观锁、拆分更新、排队等）。

🔸 ERROR 1213 (HY000) : Deadlock

原因：事务间形成了循环等待，OceanBase 会自动选择一个事务回滚打破死锁。
解决：应用程序捕获该错误后重试事务。可通过 DBA_OB_DEADLOCK_EVENT_HISTORY 视图分析死锁原因。

🔸 ERROR 6002 (HY000) : Transaction is killed

原因：事务被手动或系统终止（如通过 KILL SESSION 或达到资源限制）。
解决：重新执行事务，并检查是否被运维操作干预。

六、Oracle 模式特有错误码

🔸 ORA-00942: table or view does not exist

原因：表或视图不存在，或当前用户无权限访问。
解决：确认表名拼写，检查 user_tables 或 all_tables，并授予 SELECT 权限。

🔸 ORA-01017: invalid username/password; logon denied

原因：用户名或密码错误。
解决：确认凭证，或使用 ALTER USER username IDENTIFIED BY new_password; 重置密码。

🔸 ORA-01403: no data found

原因：PL/SQL 中的 SELECT INTO 语句未返回任何行。
解决：使用 EXCEPTION WHEN NO_DATA_FOUND THEN ... 处理异常，或改用游标查询。

🔸 ORA-01438: value larger than specified precision allowed for this column

原因：数值超出列定义的精度（如 NUMBER(5,2) 存储 1234.5）。
解决：扩大列精度或调整数值。

🔸 ORA-01722: invalid number

原因：字符串无法转换为数字。
解决：检查数据，使用 TO_NUMBER 时确保格式匹配，或先用正则过滤非法字符。

🔸 ORA-01843: not a valid month

原因：日期格式字符串与格式掩码不匹配，例如 ‘13’ 作为月份。
解决：使用 TO_DATE 时指定正确的 fmt 参数，如 TO_DATE('2025-13-01','YYYY-MM-DD') 会报此错误。

🔸 ORA-02291: integrity constraint violated - parent key not found

原因：插入或更新子表外键列时，对应的父表主键不存在。
解决：先插入父表记录，或暂时禁用外键约束（生产环境慎用）。

🔸 ORA-02292: integrity constraint violated - child record found

原因：删除父表记录时，子表仍有引用该记录的外键数据。
解决：先删除子表相关数据，或使用 DELETE FROM parent WHERE ... CASCADE CONSTRAINTS;（需权限）。

🔸 ORA-04091: table is mutating, trigger/function may not see it

原因：行级触发器中试图读取或修改触发表本身，导致变异表错误。
解决：重写触发器，改用复合触发器（Compound Trigger）或临时表来绕过。

🔸 ORA-06530: Reference to uninitialized composite

原因：使用了未初始化的对象或集合。
解决：使用构造函数初始化，如 l_obj := my_obj_type(NULL, ...); 或 l_col := my_collection_type();

🔸 ORA-06531: Reference to uninitialized collection

原因：嵌套表或 VARRAY 未初始化。
解决：调用集合的构造函数：l_table := my_table_type();

🔸 ORA-06550: PL/SQL: numeric or value error

原因：PL/SQL 中算术运算、类型转换或约束违反。
解决：检查变量声明、赋值和运算，确保值不超出范围。

🔸 ORA-00904: invalid identifier

原因：标识符（列名、别名、变量名）无效或拼写错误。
解决：检查名称是否在作用域内，注意大小写（双引号内区分大小写）。

🔸 ORA-00933: SQL command not properly ended

原因：SQL 语法错误，如缺少分号、关键字错位、括号不匹配等。
解决：逐段检查 SQL，可借助 SQL 格式化工具辅助排查。

🔸 ORA-01031: insufficient privileges

原因：当前用户缺少执行该操作所需的系统权限或对象权限。
解决：联系 DBA 授予对应权限，例如 GRANT CREATE SESSION TO user; 或 GRANT SELECT ON table TO user;

🔸 OBE-00600: internal error code, arguments: %d, %s

现象：OceanBase Oracle 模式下的内部错误，其中第一个参数是 OceanBase 内部错误码，第二个参数是错误描述。
解决：根据内部错误码查阅本文档或其他官方资料，若无法自行解决则联系技术支持。

🔸 PLS-00103: Encountered the symbol ... when expecting one of the following

原因：PL/SQL 语法错误，例如缺少分号、关键字写错、声明顺序错误等。
解决：检查代码，参照 Oracle PL/SQL 语法规范修正。

🔸 PLS-00201: identifier '%.*s' must be declared

原因：引用的变量、游标、子程序等未声明，或声明位置错误。
解决：检查标识符拼写，确保声明在使用之前，且作用域正确。

🔸 PLS-00306: wrong number or types of arguments in call

原因：调用过程或函数时传递的参数个数或类型与定义不匹配。
解决：检查函数/过程的参数列表，调整调用语句。

🔸 PLS-00428: an INTO clause is expected in this SELECT statement

原因：在 PL/SQL 块中使用的 SELECT 语句没有 INTO 子句来接收返回值。
解决：添加 INTO 变量列表，例如 SELECT ... INTO v_var1, v_var2 FROM ...;

七、错误排查通用流程

当遇到未知或罕见错误码时，可遵循以下标准流程进行排查：

1. 快速查询错误码含义：使用 ob_error <错误码> 获取官方解释和解决建议。
2. 捕获完整错误信息：包括错误码、SQLSTATE、错误消息、发生时间、执行 SQL 语句及参数。
3. 查阅官方文档：OceanBase 官网提供按错误码分类的详细说明和常见案例。
4. 检查相关日志：
   • observer.log：存储 OBServer 节点运行信息，包含大量调试和错误详情。
   • rootservice.log：Root Service 相关日志，涉及租户、资源管理等。
   • election.log：选举模块日志，用于排查 Leader 切换、无主等问题。
5. 分析触发条件：结合业务场景（并发量、数据量、操作类型）复现问题，缩小范围。
6. 尝试应急措施：如调整超时参数、增加内存、重启节点等，但应在业务低峰期操作。
7. 升级版本：确认是否为已知 Bug，可参照社区或官方发布的修复版本进行升级。
8. 联系技术支持：对于内部错误码（如 4000、4001、4016、4388 等）或无法定位的问题，提供完整日志和复现步骤给 OceanBase 技术团队。

性能抖动（Performance Jitter）是指数据库系统在正常负载下突然出现响应时间增大、吞吐量下降、CPU 飙升或连接堆积等现象，通常持续数秒至数分钟，随后自行恢复。与持续的性能瓶颈不同，抖动往往由后台任务、突发流量、锁冲突或资源竞争等瞬时因素触发。本章提供一套系统化的排查方法论，帮助 DBA 快速定位抖动根因并采取有效应对措施。

一、排查前置准备：构建可观测性基线

在发生抖动时，能够快速获取历史数据是定位问题的关键。建议提前部署以下监控手段：

• OCP 监控大盘：配置租户级 QPS、RT、CPU 使用率、内存使用率、磁盘 IO 等关键指标的实时监控和告警。
• 慢查询采集：开启 slow_query_log 并设置合理的 long_query_time（如 100ms），定期采集慢 SQL。
• 系统日志保留策略：确保 observer.log、rootservice.log、election.log 保留足够时长（建议至少 7 天），并配置日志轮转。
• 定期快照：使用 GV$OB_SQL_AUDIT 定期采集 Top SQL 快照，便于事后对比。
• 部署 obdiag 工具：通过 obdiag check 定期执行巡检，一键采集诊断信息。

二、排查流程（从整体到局部）

当收到抖动告警或用户反馈时，可按以下步骤系统化排查：

步骤 1：确认抖动的时间范围和影响范围

• 询问业务方具体的抖动时间点（精确到分钟），收集应用日志中的错误和超时记录。
• 通过 OCP 或系统视图查看该时间段的集群全局指标，判断是单个租户、单个节点还是整体集群问题。
• 关键查询：SELECT * FROM oceanbase.GV$OB_SERVERS 查看节点状态；SELECT * FROM oceanbase.GV$OB_UNITS 查看租户资源分布。

步骤 2：关联后台任务（合并、转储、备份、迁移）

性能抖动最常见的诱因是后台任务的突增资源消耗。使用以下视图快速排查：

-- 查看合并任务（Major Compaction）进度
        SELECT * FROM oceanbase.DBA_OB_MAJOR_COMPACTION;

        -- 查看转储任务（Minor Compaction）状态
        SELECT * FROM oceanbase.GV$OB_COMPACTION_PROGRESS;

        -- 查看数据备份任务
        SELECT * FROM oceanbase.CDB_OB_BACKUP_JOBS;

        -- 查看 Unit 迁移任务
        SELECT * FROM oceanbase.DBA_OB_UNIT_JOBS;

判断标准：若抖动时间点与后台任务的开始/结束时间高度重合，则根因为后台任务干扰。可采取以下措施：

• 调整合并时间窗口，将 major_freeze_duty_time 设置在业务低峰期。
• 适当降低合并并发度（compaction_low_thread_score）或使用限流参数。
• 若备份任务影响过大，可错峰调度或限制备份带宽（sys_bkgd_net_percentage）。

步骤 3：分析慢查询与执行计划突变

若抖动期间 QPS 并未明显下降，但延迟升高，通常是某些 SQL 执行计划劣化或出现了大查询。

-- 查找抖动时间点附近执行时间最长的 SQL
        SELECT request_time, elapsed_time, queue_time, execute_time, query_sql
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time BETWEEN start_time_micros AND end_time_micros
        ORDER BY elapsed_time DESC
        LIMIT 20;

        -- 查看 SQL 的计划缓存信息，确认是否使用了错误的索引或 Join 顺序
        SELECT plan_id, outline_id, outline_data 
        FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_EXPLAIN 
        WHERE sql_id = '...';

常见原因与对策：

• 统计信息过旧：执行 ANALYZE TABLE 或 DBMS_STATS.GATHER_TABLE_STATS 更新统计信息。
• 索引失效：检查是否因数据分布变化导致优化器选择了全表扫描，使用 Outline 绑定执行计划。
• 并行度不适当：若大查询开启了过高并行度（Auto DOP 评估过高），可通过 parallel_servers_target 限制总并行资源。

步骤 4：排查锁冲突与事务堵塞

长事务或未提交的事务会持有锁，阻塞后续操作，导致响应时间飙升。

-- 查看当前锁等待关系
        SELECT * FROM oceanbase.GV$OB_TRX_LOCK_WAIT;

        -- 查看长时间未提交的事务（例如超过 1 小时）
        SELECT trans_id, tenant_id, svr_ip, trans_start_time, trans_timeout
        FROM oceanbase.GV$OB_TRANSACTION
        WHERE trans_start_time < DATE_SUB(NOW(), INTERVAL 1 HOUR);

处理方式：若发现阻塞源头，可 kill 阻塞会话：KILL session_id;。同时检查应用代码，避免在事务中执行非必要操作，及时提交或回滚。

步骤 5：分析资源使用异常（CPU / 内存 / IO）

• CPU 飙升：通过 top -H -p pidof observer 查看线程 CPU 占用，结合 observer.log 中的 trace_id 定位具体 SQL 或任务。
• 内存持续增长：查询 GV$OB_MEMORY 跟踪各模块内存变化，重点关注 Plan Cache、KVCache、SQL Work Area。若存在泄漏迹象，可临时执行 ALTER SYSTEM FLUSH PLAN CACHE; 释放内存。
• 磁盘 IO 飙高：使用 iostat -x 1 观察磁盘 util 和 await，确认是否由合并、转储或备份引起。必要时调整合并限速参数 _ob_compaction_throttling（建议 0.2 或 0.5）。

-- 查看租户 MemStore 使用情况
        SELECT tenant_id, svr_ip, 
            round(ACTIVE_MEMSTORE_USED/1024/1024/1024,2) AS active_gb,
            round(TOTAL_MEMSTORE_USED/1024/1024/1024,2) AS total_gb,
            round(MEMSTORE_LIMIT/1024/1024/1024,2) AS limit_gb,
            round(TOTAL_MEMSTORE_USED/MEMSTORE_LIMIT*100,2) AS pct
        FROM oceanbase.GV$OB_MEMSTORE
        WHERE tenant_id = 1002;

步骤 6：网络抖动排查

跨节点部署的 OceanBase 集群对网络延迟敏感。若怀疑网络问题，可：

• 检查 observer.log 中是否有大量 RPC timeout 或 connection refused 日志。
• 使用 ping 和 netstat -s 检测网络丢包和重传率。
• 确认交换机、防火墙未做限流，且各节点时间同步偏差在 2 秒以内（使用 NTP/chrony）。

三、典型场景速查表

四、自动化诊断工具：obdiag

obdiag 是 OceanBase 官方提供的敏捷诊断工具，可以一键采集系统状态、慢日志、ASH 报告等，大幅提升排查效率。以下命令可在抖动发生后快速获取诊断数据：

# 一键巡检集群（包含 OBServer、OBProxy 状态、参数检查等）
        obdiag check run

        # 采集当前系统状态快照（CPU、内存、磁盘、网络、进程等）
        obdiag gather sysstat

        # 采集性能报告（包含等待事件、Top SQL、锁等）
        obdiag gather perf

        # 采集慢查询日志（自动从 observer.log 和 obproxy_slow.log 提取）
        obdiag gather slowlog --since "1 hour ago"

        # 采集指定 trace_id 的全链路日志
        obdiag gather trace --trace_id "YB420ABF87A4-0005FEA36C9B5B7A"

        # 采集 ASH 报告（活跃会话历史）
        obdiag gather ash --from "2025-06-15 14:00:00" --to "2025-06-15 14:30:00" --report_type=HTML

五、应急处理与长期优化建议

日志是数据库运维和问题诊断的核心数据源。OceanBase 数据库提供了多层次、多模块的日志体系，覆盖系统运行、选举、Root Service、SQL 审计等各个维度。掌握日志分析方法，能够帮助 DBA 快速定位故障根因、追溯历史事件、分析性能瓶颈。本章系统介绍 OceanBase 4.x 的日志体系、配置方法、分析技巧以及常用调试工具。

一、日志级别与动态调整

OceanBase 支持标准的日志级别（从低到高）：DEBUG < TRACE < INFO < WARN < USER_ERR < ERROR。默认级别为 INFO，生产环境不建议调低到 DEBUG，以免产生大量日志影响性能。此外，OceanBase 还提供了 WDIAG 和 EDIAG 两个特殊诊断级别，分别用于记录普通诊断信息和错误诊断信息。

查看当前日志级别

-- 系统租户下查看日志级别配置
        SHOW PARAMETERS LIKE 'syslog_level';

        -- 查看所有模块的日志级别（结果格式：module_name:level）
        SELECT * FROM oceanbase.GV$OB_LOG_LEVEL;

动态调整日志级别（无需重启）

可以针对特定模块调整日志级别，用于临时调试。例如，将 SQL 执行模块的日志级别调整为 DEBUG：

-- 设置 SQL 执行模块日志级别为 DEBUG
        ALTER SYSTEM SET syslog_level = 'sql.executor:DEBUG';

        -- 恢复全局默认 INFO 级别（所有模块）
        ALTER SYSTEM SET syslog_level = 'INFO';

        -- 同时调整多个模块
        ALTER SYSTEM SET syslog_level = 'sql.executor:DEBUG,storage.compaction:WARN';

二、日志分析与关键信息提取

1. 使用 trace_id 全链路追踪

OceanBase 为每个 SQL 请求分配一个全局唯一的 trace_id（格式类似 YB42C00031AB-0005E720D5FF1D2A）。该 ID 会贯穿整个分布式执行链路，出现在相关节点的日志中。通过 trace_id 可以在多个节点的日志中关联同一请求的完整执行路径。

-- 在 SQL 审计视图中获取 trace_id
        SELECT trace_id, elapsed_time, query_sql 
        FROM oceanbase.GV$OB_SQL_AUDIT 
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000
        LIMIT 10;

        -- 在 observer.log 中搜索 trace_id（所有节点）
        grep "trace_id=YB42C00031AB-0005E720D5FF1D2A" /home/admin/oceanbase/log/observer.log*

2. 根据错误码快速定位

日志中经常出现形如 ret=-4012 或 ERROR 4012 的错误码。结合错误码查阅文档或本章 12.1 节，可快速了解问题类型。在日志中搜索错误码并查看前后上下文，通常能发现触发条件。

3. 分析合并与转储相关日志

合并和转储相关日志通常包含关键词 compaction、minor freeze、major freeze。通过查看这些日志可以判断合并是否卡住、超时或资源不足。

# 查看合并进度相关日志
        grep -E "major freeze|compaction" /home/admin/oceanbase/log/observer.log | tail -100

        # 查找合并超时或失败信息
        grep -E "major freeze.*failed|compaction.*timeout" /home/admin/oceanbase/log/observer.log

4. 定位网络或 RPC 问题

搜索 RPC timeout、connection refused、send error 等关键词，可发现节点间通信异常。结合 election.log 排查选举相关网络问题。

三、日志轮转与清理策略

日志文件无限增长可能导致磁盘写满，OceanBase 提供了自动轮转和回收机制。

-- 开启系统日志自动回收
        ALTER SYSTEM SET enable_syslog_recycle = True;

        -- 设置保留的日志文件最大数量（默认 300）
        ALTER SYSTEM SET max_syslog_file_count = 500;

        -- 手动执行日志清理（如删除 7 天前的日志）
        # 在操作系统层面可使用 logrotate 或自定义脚本，但注意不要直接 rm 正在写入的文件

四、自动化诊断工具：obdiag

OceanBase 官方提供的 obdiag 工具能够一键采集诊断信息，自动分析常见问题，大幅提升排查效率。

常用命令

# 一键巡检集群（包含 OBProxy、OBServer 状态、参数检查等）
        obdiag check run

        # 按时间段批量收集日志（核心命令）
        obdiag gather log --from "2025-06-15 14:00:00" --to "2025-06-15 15:00:00"

        # 使用 since 参数收集最近一段时间内的日志
        obdiag gather log --since "30m" --scope observer

        # 根据关键词筛选日志
        obdiag gather log --since "1h" --grep "ERROR" --scope observer

        # 收集集群主机信息（dmesg、CPU、内存等）
        obdiag gather log --scope host --since "5m"

        # 收集指定 trace_id 的全链路日志
        obdiag gather log --trace_id YB42C00031AB-0005E720D5FF1D2A

        # 收集系统状态快照（CPU、内存、磁盘、网络、进程等）
        obdiag gather sysstat

其中 obdiag gather log 支持灵活的收集范围，可通过 --scope 指定日志类型（observer/election/rootservice/all），通过 --since 指定相对时间，通过 --from/--to 指定绝对时间。obdiag 会生成压缩包和 HTML 格式的报告，包含关键日志摘要和优化建议，非常适合快速初筛。

五、高级调试技巧

1. 开启特定模块的 DEBUG 日志

当需要深入了解某个功能（如 SQL 优化器、存储引擎）的内部行为时，可临时调整对应模块的日志级别。注意先在测试环境验证。

-- 开启 SQL 优化器 DEBUG 日志
        ALTER SYSTEM SET syslog_level = 'sql.optimizer:DEBUG';

        -- 开启事务模块 TRACE 日志
        ALTER SYSTEM SET syslog_level = 'transaction:TRACE';

2. 使用 ob_admin 解析底层日志

ob_admin 是 OceanBase 提供的底层运维工具，内置了 clog_tool 模块，可以解析事务提交日志（clog）和 SSTable，用于排查数据不一致、数据丢失等深层次问题。常用命令如下：

# 解析并打印指定的 clog 文件（基础命令）
        ./ob_admin clog_tool dump_log 

        # 以类 SQL 格式解析 clog，提升可读性
        ./ob_admin clog_tool dump_format 

        # 按十六进制格式打印日志（处理不可打印字符）
        ./ob_admin clog_tool dump_hex 

        # 按过滤条件解析 clog（例如按 table_id 过滤）
        ./ob_admin clog_tool dump_filter 'table_id=1100611139457011' 

以 dump_format 命令为例，它会将日志解析为类 SQL 格式，输出的 trans_id、DML 类型、table_id 以及具体修改内容一目了然，是定位数据正确性问题的利器。使用 dump_hex 则可处理包含不可打印字符的日志。

3. debug_sync 同步点调试

OceanBase 提供了与 MySQL 兼容的 debug_sync 机制，允许在代码关键位置设置同步点，用于复现并发竞争条件。可以通过设置 Session 变量 debug_sync 或系统变量 ob_global_debug_sync 开启。该功能主要用于数据库内核开发调试，生产环境默认关闭。

4. 全链路追踪（Trace Log）

全链路追踪是 OceanBase 4.x 版本引入的强大诊断功能，能够追踪用户 SQL 请求在数据库全链路过程中，在不同组件、不同阶段执行的相关信息，并以可视化方式展现。

OceanBase 数据库企业版支持 Session 级别的全链路追踪，可通过 DBMS_MONITOR.OB_SESSION_TRACE_ENABLE 存储过程开启。该过程支持三个跟踪级别：Level 1 记录关键阶段信息；Level 2 在 Level 1 基础上增加更多细节；Level 3 输出最详细的内部调用栈，适用于深度问题诊断。

在 Oracle 模式下，可通过 DBMS_MONITOR 包控制追踪开关及日志打印细节。全链路追踪的日志会同时记录在 OBProxy 的 obproxy_trace.log 和 OBServer 的 trace.log 中，每个日志文件大小限制为 256MB。

六、日志分析典型案例

案例 1：SQL 超时（ret=-4012）

日志特征：WARN [SQL] execute timeout, ret=-4012, query_timeout=... trace_id=...
分析步骤：

1. 根据 trace_id 在 observer.log 中搜索，确认该 SQL 在哪个节点执行。
2. 查看同一 trace_id 的其他日志，判断是执行计划复杂还是等待锁资源。
3. 若为执行计划问题，通过 GV$OB_PLAN_CACHE_PLAN_EXPLAIN 查看计划，优化 SQL 或调大超时参数。

案例 2：合并卡住（major freeze 长时间未完成）

日志特征：major freeze progress 停滞在某个百分比，或出现 timeout waiting for tablet merge。
分析步骤：

1. 查询 DBA_OB_MAJOR_COMPACTION 查看合并状态和卡住的分区。
2. 在 observer.log 中搜索对应分区 ID 或 compaction 关键词，查看是否有错误（如磁盘满、内存不足）。
3. 若长期卡住，可尝试手动取消合并：ALTER SYSTEM CANCEL MAJOR FREEZE TENANT = tenant_name;，然后重新触发。

案例 3：Leader 切换频繁（election.log 大量选举日志）

日志特征：election.log 中出现 start election、become leader、leader lease expired 等高频事件。
分析步骤：

1. 检查网络延迟（ping 测试）和时间同步（ntpstat）。
2. 查看节点 CPU 负载是否过高导致租约超时。
3. 检查是否有节点频繁宕机或重启。

SQL Audit（SQL 审计）是 OceanBase 数据库提供的一项核心诊断功能，通过系统视图 GV$OB_SQL_AUDIT（从 V4.0.0 版本开始引入）记录集群中每一次 SQL 请求的完整执行信息，包括来源、执行状态、资源消耗、等待事件及执行各阶段耗时等。该视图是 SQL 性能诊断和问题排查的利器，能够帮助 DBA 快速定位慢查询、分析瓶颈、追踪问题 SQL 的全链路执行过程。

一、启用与配置 SQL Audit

1. 开启 SQL Audit 功能

SQL Audit 功能默认开启，可通过集群级配置项 enable_sql_audit 全局控制。若需关闭或重新开启，执行以下命令：

-- 开启 SQL Audit（默认开启）
        ALTER SYSTEM SET enable_sql_audit = true;

        -- 关闭 SQL Audit（谨慎操作，关闭后将无法记录 SQL 审计信息）
        ALTER SYSTEM SET enable_sql_audit = false;

该配置项为布尔类型，默认值为 True，修改后无需重启 OBServer 节点，动态生效。

2. 租户级开关

除了集群级开关，还可以通过租户级系统变量 ob_enable_sql_audit 控制当前租户是否开启 SQL Audit 功能：

-- 开启当前租户的 SQL Audit
        SET GLOBAL ob_enable_sql_audit = true;

        -- 查看当前租户的 SQL Audit 状态
        SHOW VARIABLES LIKE 'ob_enable_sql_audit';

该变量默认值为 true，生效范围为 Global，支持通过 SET 语句修改。

3. 内存配额配置

SQL Audit 使用独立的内存空间，通过租户级系统变量 ob_sql_audit_percentage 控制 SQL Audit 功能占用租户内存的百分比。实际可用内存上限为 ob_sql_audit_percentage% × 租户内存，同时受限于约 1GB 的内部硬限制。

-- 设置 SQL Audit 内存占租户内存的百分比（默认 3%，取值范围 [0,80]）
        SET GLOBAL ob_sql_audit_percentage = 3;

二、SQL Audit 淘汰机制

SQL Audit 的记录存放在可配置的内存空间中，内存有限，因此需要淘汰机制。每个租户的后台任务每隔 1 秒 检查内存使用情况，决定是否触发淘汰。淘汰机制如下：

三、GV$OB_SQL_AUDIT 核心字段详解

该视图字段丰富，按功能分类介绍如下：

📌 请求标识字段

📌 来源与目标字段

📌 执行结果与性能指标字段

📌 时间分解字段（性能分析核心）

SQL 执行的完整耗时分解如下，单位为微秒：

• ELAPSED_TIME：从请求到达到执行结束的总时间，由以下子阶段组成。
• NET_TIME：发送 RPC 到接收到请求的时间。
• NET_WAIT_TIME：接收到请求到进入队列的时间。
• QUEUE_TIME：队列等待时间，反映当前租户的请求积压情况。若该值较大，说明系统负载高或租户线程资源不足。
• DECODE_TIME：出队列后 Decode 请求的时间。
• GET_PLAN_TIME：生成执行计划的时间，反映 Plan Cache 的健康状况。若该值较大，可能是 SQL 未命中 Plan Cache 导致硬解析。
• EXECUTE_TIME：计划的实际执行时间，由 CPU 时间和等待时间组成。
• TOTAL_WAIT_TIME_MICRO：执行过程中所有等待的总时间。

📌 等待事件字段

📌 执行计划相关字段

• PLAN_TYPE：执行计划类型。1 表示本地计划（Local），2 表示远程计划（Remote），3 表示分布式计划（Distribute），0 表示无执行计划（如 COMMIT 语句）。本地计划性能最佳，远程次之，分布式最差。若分布式计划占比过高，需检查 SQL 是否命中分区裁剪或是否需要调整分区策略。
• IS_HIT_PLAN：是否命中 Plan Cache。命中表示软解析，未命中表示硬解析，硬解析会增加耗时。若租户 Plan Cache 命中率过低，应检查 Plan Cache 空间是否过小导致计划频繁被淘汰。
• PLAN_HASH：执行计划的 Hash 值，可用于判断同一 SQL_ID 的不同执行是否存在计划变化。

四、典型使用场景与 SQL 示例

场景 1：定位慢查询（按总耗时排序）

SELECT usec_to_time(request_time) AS request_time,
            elapsed_time/1000 AS elapsed_ms,
            execute_time/1000 AS exec_ms,
            queue_time/1000 AS queue_ms,
            plan_type,
            sql_id,
            query_sql
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000  -- 最近 1 小时
        ORDER BY elapsed_time DESC
        LIMIT 20;

通过 ELAPSED_TIME 快速找出执行时间最长的 SQL，并结合 QUEUE_TIME、EXECUTE_TIME 等字段初步判断瓶颈阶段。

场景 2：分析某类 SQL 的聚合统计（按 SQL_ID 分组）

SELECT sql_id,
            COUNT(*) AS exec_count,
            AVG(elapsed_time) AS avg_us,
            MAX(elapsed_time) AS max_us,
            AVG(queue_time) AS avg_queue_us,
            AVG(get_plan_time) AS avg_get_plan_us
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000
        GROUP BY sql_id
        ORDER BY avg_us DESC
        LIMIT 20;

统计各类 SQL 的平均耗时、最大耗时、排队时间等，识别需要优化的 SQL 类型。

场景 3：根据 TRACE_ID 全链路追踪

SELECT * FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE trace_id = 'YB420ABF87A4-0005FEA36C9B5B7A'\G

获取该 SQL 的完整执行信息，并在日志中搜索同一 TRACE_ID，实现应用与数据库端的全链路关联。

场景 4：分析 Plan Cache 命中率

SELECT COUNT(*) AS total,
            SUM(CASE WHEN is_hit_plan = 1 THEN 1 ELSE 0 END) AS hit_count,
            ROUND(SUM(CASE WHEN is_hit_plan = 1 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS hit_rate
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000;

若命中率偏低，应检查 plan_cache_high_water_mark 等参数，合理分配 Plan Cache 内存空间。

场景 5：分析分布式计划占比

SELECT plan_type,
            COUNT(*) AS cnt,
            ROUND(COUNT(*) / SUM(COUNT(*)) OVER() * 100, 2) AS pct
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000
        AND plan_type IN (1, 2, 3)
        GROUP BY plan_type;

若 plan_type=3（分布式计划）占比过高，说明大量 SQL 涉及跨分区/跨节点访问，需检查分区键是否合理或分区裁剪是否生效。

场景 6：定位等待事件瓶颈

SELECT event, wait_class, COUNT(*) AS cnt,
            AVG(total_wait_time_micro) AS avg_wait_us,
            SUM(total_wait_time_micro) AS total_wait_us
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000
        AND total_wait_time_micro > 0
        GROUP BY event, wait_class
        ORDER BY total_wait_us DESC
        LIMIT 10;

找出导致总等待时间最长的等待事件类型，针对性地进行优化（如磁盘 IO 慢需调整存储、锁等待需排查事务冲突等）。

五、命令行一键采集 SQL Audit 数据

OceanBase 官方诊断工具 obdiag 支持一键采集 SQL Audit 数据，便于离线分析或留存历史快照。

# 采集最近 1 小时的 SQL Audit 数据
        obdiag gather sql_audit --since "1h"

        # 采集指定时间段的 SQL Audit 数据
        obdiag gather sql_audit --from "2025-06-15 14:00:00" --to "2025-06-15 15:00:00"

        # 仅采集慢查询（elapsed_time > 100ms）
        obdiag gather sql_audit --since "1h" --slow_query_threshold "100ms"

        # 按 SQL_ID 过滤采集
        obdiag gather sql_audit --since "1h" --sql_id "195E74D0ACE24FF470774DF649D62921"

执行后，obdiag 会生成一个压缩包，内含该时间段的 SQL Audit 数据（JSON 格式），可导入到其他分析工具或留存备查。

六、视图兼容性与版本说明

• 视图名称变化：OceanBase 4.0.0.0 及以上版本使用 GV$OB_SQL_AUDIT，V3.x 及更早版本使用 GV$SQL_AUDIT。查询时需根据版本选择正确的视图名称。
• 租户隔离：该视图按租户拆分。系统租户（sys）可以查询所有租户的数据；普通租户只能查询本租户的数据。
• PL 请求的 SQL_ID 展示：从 V4.2.3 版本（V4.2.x）和 V4.3.2 版本（V4.3.x）开始，针对 CALL 语句执行的 PL 请求和通过匿名块执行的 PL 请求，SQL_ID 字段会展示为实际生成的 MD5 编码。
• SID 字段的含义：在不同连接方式下有所差异——直连模式下为服务端 Session ID；ODP 模式下当 ODP 配置 client_session_id_version = 2 时为客户端 Session ID，否则为服务端 Session ID。

七、最佳实践与注意事项

OceanBase 数据库提供了一系列动态性能视图（Dynamic Performance Views），用于实时监控数据库的运行状态、资源消耗、会话活动、锁等待以及 SQL 执行情况等关键指标。这些视图是 DBA 进行性能诊断和问题排查的核心工具。本章系统梳理 OceanBase 4.x 中最常用的动态性能视图，介绍各视图的功能定位、关键字段含义以及典型使用场景。

一、性能视图体系分类概览

OceanBase 数据库的性能视图覆盖多个维度，以下按功能类别进行划分：

📊 SQL 诊断类视图

🔐 事务与锁相关视图

💾 内存与资源监控视图

⚙️ 后台任务与负载均衡视图

👥 会话与等待事件视图

二、核心视图详解

1. GV$OB_SQL_AUDIT——SQL 审计核心视图

GV$OB_SQL_AUDIT 是 OceanBase 数据库中最常用的 SQL 监控视图，能够记录每一次 SQL 请求的来源、执行状态、资源消耗、等待事件等统计信息。从 V4.0.0 版本开始引入。该视图是按租户拆分的，系统租户可以查询所有租户的数据，普通租户只能查询本租户的数据。

核心字段说明：

-- 查找最近 1 小时内最慢的 20 条 SQL
        SELECT usec_to_time(request_time) AS request_time,
            elapsed_time/1000 AS elapsed_ms,
            queue_time/1000 AS queue_ms,
            execute_time/1000 AS exec_ms,
            sql_id, plan_type, query_sql
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE request_time > UNIX_TIMESTAMP() * 1000000 - 3600000000
        ORDER BY elapsed_time DESC
        LIMIT 20;

        -- 分析 SQL 的执行耗时构成
        SELECT trace_id, elapsed_time, queue_time, get_plan_time, execute_time
        FROM oceanbase.GV$OB_SQL_AUDIT
        WHERE sql_id = 'your_sql_id'
        ORDER BY request_time DESC
        LIMIT 10;

2. GV$OB_PLAN_CACHE_PLAN_STAT——计划缓存统计

该视图展示当前租户在所有 OBServer 节点上的计划缓存中缓存的每一个对象的状态，从 V4.0.0 版本开始引入。它不仅缓存了 SQL 计划对象，还缓存了 PL 对象（如匿名块、Package 以及 Function）。

核心字段说明：

• SQL_ID：缓存对象对应的 SQL ID，如果是 PL 对象则为 NULL。
• TYPE：缓存对象的类型——对于 SQL 计划：1=Local Plan，2=Remote Plan，3=Distribute Plan；对于 PL 对象：1=Procedure，2=Function，3=Package，4=Anonymous Block。
• EXECUTIONS：执行次数。
• AVG_EXE_USEC：平均执行时间（微秒）。
• HIT_COUNT：被命中次数，反映该计划的使用频率。
• PLAN_SIZE：缓存对象占用的内存大小。
• SLOW_COUNT：当前 SQL 计划成为慢查询的次数。

-- 查询执行次数最多的 SQL 计划
        SELECT sql_id, type, executions, avg_exe_usec/1000 AS avg_ms, hit_count
        FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT
        WHERE sql_id IS NOT NULL
        ORDER BY executions DESC
        LIMIT 20;

        -- 查看计划缓存内存占用（按租户聚合）
        SELECT tenant_id, SUM(plan_size) AS total_plan_cache_bytes
        FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT
        GROUP BY tenant_id;