---
title: x86 切换 ARM 后参数相同的高频 SQL 走 SSTable 单行读取并回表，引发 CAS 原子竞争导致 CPU 打满-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于x86 切换 ARM 后参数相同的高频 SQL 走 SSTable 单行读取并回表，引发 CAS 原子竞争导致 CPU 打满相关的常见问题和使用技巧，帮助您快速解决x86 切换 ARM 后参数相同的高频 SQL 走 SSTable 单行读取并回表，引发 CAS 原子竞争导致 CPU 打满的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# x86 切换 ARM 后参数相同的高频 SQL 走 SSTable 单行读取并回表，引发 CAS 原子竞争导致 CPU 打满

更新时间：2026-08-25 06:51

适用版本： V4.2.x 内容类型：Troubleshoot  

## 问题现象

集群从 x86 切换至 ARM 后，核心业务队列积压，当时单表 T_MAIN 的 Leader 30 节点 CPU 打满。

SQL 响应时间达几百毫秒。

查看当时 30 节点上已经存在严重的队列积压，且积压在 queue4，即 normal SQL 队列。

通过 processlist 观察到几乎为 DE3E302D210B5E8EED200B62C28C189D 这条 SQL ID，该 SQL 为一条 select 33 列的查询语句：

```sql
select t.COL_01 as COL_01_ALIAS, t.COL_02 as COL_02_ALIAS, ... , t.COL_33 as COL_33_ALIAS from T_MAIN t where (t.COL_16=? and t.COL_18<>?)

```

结合现场查询情况，该慢 SQL 的业务传参几乎一样，查询条件为 t.COL_16=99100000 且 t.COL_18<>3。

执行计划在 Where 条件的扫描上，最终返回 551 行，时间开销均在执行时间上，并未发现计划不合理之处，且观察了 x86 环境计划也无不同之处。执行计划如下：

```sql
obclient [oceanbase]> select * from gv$plan_cache_plan_explain where ip='x.x.x.x'  and port=2882 and tenant_id=1012 and plan_id=12947;
  +-----------+-------------+------+---------+------------+--------------+----------------+----------------------------------+------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  | TENANT_ID | IP          | PORT | PLAN_ID | PLAN_DEPTH | PLAN_LINE_ID | OPERATOR       | NAME                             | ROWS | COST | PROPERTY                                                                                                                                                                                                                  |
  +-----------+-------------+------+---------+------------+--------------+----------------+----------------------------------+------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  |      1012 | x.x.x.x     | 2882 |   12947 |          0 |            0 | PHY_TABLE_SCAN | T_MAIN(IDX_COL_02_16)            |  551 | 3603 | table_rows:317658, physical_range_rows:551, logical_range_rows:551, index_back_rows:551,output_rows:551, est_method:local_storage, avaiable_index_name[IDX_COL_02_16], pruned_index_name[IDX_COL_14,IDX_COL_13,IDX_COL_02,UK_T_MAIN_CODE,IDX_COL_07_08,T_MAIN], estimationinfo[table_id:1112705767468312, (table_type:1, version:0-1779758531565485-1779758531565485, logical_rc:551, physical_rc:551), (table_type:0, version:1779733298299187-1779733298299187-9223372036854775807, logical_rc:0, physical_rc:0)] |
  +-----------+-------------+------+---------+------------+--------------+----------------+----------------------------------+------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  1 row in set (0.009 sec)

  ===============================================================
  |ID|OPERATOR  |NAME                            |EST. ROWS|COST|
  ---------------------------------------------------------------
  |0 |TABLE SCAN|T_MAIN(IDX_COL_02_16)           |571      |3898|
  ===============================================================

  Outputs & filters:
  -------------------------------------
    0 - output([THIS_.COL_01(0xff9f47b6b9d0)], [THIS_.COL_15(0xff9f47b6c000)], [THIS_.COL_14(0xff9f47b6c630)], [THIS_.COL_13(0xff9f47b6cc60)], [THIS_.COL_12(0xff9f47b6d290)], [THIS_.COL_11(0xff9f47b6d8c0)], [THIS_.COL_17(0xff9f47b6def0)],
  [THIS_.COL_18(0xff9f47b6e520)], [THIS_.COL_06(0xff9f47b6eb50)], [THIS_.COL_07(0xff9f47b6f180)], [THIS_.COL_10(0xff9f47b6f7b0)], [THIS_.COL_08(0xff9f47b6fde0)], [THIS_.COL_09(0xff9f47b70410)], [THIS_.COL_05(0xff9f47b70a40)],
  [THIS_.COL_04(0xff9f47b71070)], [THIS_.COL_02(0xff9f47b68a20)], [THIS_.COL_03(0xff9f47b739e0)], [THIS_.COL_16(0xff9f47b69b20)], [THIS_.COL_21(0xff9f47b82350)], [THIS_.COL_25(0xff9f47b82980)], [THIS_.COL_26(0xff9f47b82fb0)],
  [THIS_.COL_27(0xff9f47b835e0)], [THIS_.COL_28(0xff9f47b83c10)], [THIS_.COL_29(0xff9f47b84240)], [THIS_.COL_30(0xff9f47b84870)], [THIS_.COL_31(0xff9f47b84ea0)], [THIS_.COL_19(0xff9f47b854d0)], [THIS_.COL_20(0xff9f47b85b00)],
  [THIS_.COL_32(0xff9f47b86130)], [THIS_.COL_34(0xff9f47b86760)], [THIS_.COL_33(0xff9f47b86d90)], [THIS_.COL_23(0xff9f47b873c0)], [THIS_.COL_22(0xff9f47b879f0)]), filter([cast(cast(THIS_.COL_16(0xff9f47b69b20), VARCHAR2(3 BYTE))(0xff9f47b69e60),
  NUMBER(-1, -85))(0xff9f47b6a7f0) != 3(0xff9f47b69400)]),
        access([THIS_.COL_02(0xff9f47b68a20)], [THIS_.COL_16(0xff9f47b69b20)], [THIS_.COL_01(0xff9f47b6b9d0)], [THIS_.COL_15(0xff9f47b6c000)], [THIS_.COL_14(0xff9f47b6c630)], [THIS_.COL_13(0xff9f47b6cc60)], [THIS_.COL_12(0xff9f47b6d290)],
  [THIS_.COL_11(0xff9f47b6d8c0)], [THIS_.COL_17(0xff9f47b6def0)], [THIS_.COL_18(0xff9f47b6e520)], [THIS_.COL_06(0xff9f47b6eb50)], [THIS_.COL_07(0xff9f47b6f180)], [THIS_.COL_10(0xff9f47b6f7b0)], [THIS_.COL_08(0xff9f47b6fde0)],
  [THIS_.COL_09(0xff9f47b70410)], [THIS_.COL_05(0xff9f47b70a40)], [THIS_.COL_04(0xff9f47b71070)], [THIS_.COL_03(0xff9f47b739e0)], [THIS_.COL_21(0xff9f47b82350)], [THIS_.COL_25(0xff9f47b82980)], [THIS_.COL_26(0xff9f47b82fb0)],
  [THIS_.COL_27(0xff9f47b835e0)], [THIS_.COL_28(0xff9f47b83c10)], [THIS_.COL_29(0xff9f47b84240)], [THIS_.COL_30(0xff9f47b84870)], [THIS_.COL_31(0xff9f47b84ea0)], [THIS_.COL_19(0xff9f47b854d0)], [THIS_.COL_20(0xff9f47b85b00)],
  [THIS_.COL_32(0xff9f47b86130)], [THIS_.COL_34(0xff9f47b86760)], [THIS_.COL_33(0xff9f47b86d90)], [THIS_.COL_23(0xff9f47b873c0)], [THIS_.COL_22(0xff9f47b879f0)]), partitions(p0),
        is_index_back=true, filter_before_indexback[true],
        range_key([THIS_.COL_02(0xff9f47b68a20)], [THIS_.COL_16(0xff9f47b69b20)], [THIS_.COL_01(0xff9f47b6b9d0)]), range(99100000,MIN,MIN ; 99100000,MAX,MAX),
        range_cond([THIS_.COL_02(0xff9f47b68a20) = 99100000(0xff9f47b68300)])

  Used Hint:
  -------------------------------------
    /*+
    */

  Outline Data:
  -------------------------------------
    /*+
        BEGIN_OUTLINE_DATA
        INDEX(@"SEL$1" "SCHEMA_A.THIS_"@"SEL$1" "IDX_COL_02_16")
        END_OUTLINE_DATA
    */

  Plan Type:
  -------------------------------------
  LOCAL

  Optimization Info:
  -------------------------------------
  THIS_:table_rows:317658, physical_range_rows:1142, logical_range_rows:1142, index_back_rows:571, output_rows:571, est_method:local_storage, optimization_method=cost_based,
  avaiable_index_name[IDX_COL_02,IDX_COL_02_16,T_MAIN], pruned_index_name[IDX_COL_14,IDX_COL_13,UK_T_MAIN_CODE,IDX_COL_07_08], estimation info[table_id:1112705767468312, (table_type:1,
  version:0-1779758531565485-1779758531565485, logical_rc:1142, physical_rc:1142), (table_type:0, version:1779733298299187-1779733298299187-9223372036854775807, logical_rc:0, physical_rc:0)]

  Parameters:

```

过滤日志，查找 CPU 打高期间对应该条 SQL 的 slow query 信息，发现从回表获取行到结果集关闭（即索引回表发送数据）这段路径耗时比较长，说明耗时主要发生在索引回表及数据发送期间。

现场备份的原表结构如下：

```sql
CREATE TABLE "T_MAIN" (
  "COL_01" NUMBER(20) CONSTRAINT "T_MAIN_OBNOTNULL_1721354162376758" NOT NULL ENABLE,
  "COL_02" NUMBER(20),
  "COL_03" NUMBER(20),
  "COL_04" VARCHAR2(3),
  "COL_05" VARCHAR2(6),
  "COL_06" VARCHAR2(64),
  "COL_07" VARCHAR2(256),
  "COL_08" VARCHAR2(512),
  "COL_09" VARCHAR2(16),
  "COL_10" VARCHAR2(8),
  "COL_11" NUMBER(20),
  "COL_12" VARCHAR2(256),
  "COL_13" NUMBER(10),
  "COL_14" VARCHAR2(256),
  "COL_15" NUMBER(20),
  "COL_16" VARCHAR2(3),
  "COL_17" VARCHAR2(1024),
  "COL_18" NUMBER(5),
  "COL_19" NUMBER(20),
  "COL_20" DATE,
  "COL_21" VARCHAR2(1),
  "COL_22" VARCHAR2(32),
  "COL_23" VARCHAR2(32),
  "COL_24" NUMBER(1),
  "COL_25" VARCHAR2(50),
  "COL_26" VARCHAR2(50),
  "COL_27" VARCHAR2(50),
  "COL_28" VARCHAR2(1),
  "COL_29" DATE,
  "COL_30" NUMBER(20),
  "COL_31" NUMBER(20),
  "COL_32" NUMBER(20),
  "COL_33" VARCHAR2(256),
  "COL_34" DATE,
  "COL_35" VARCHAR2(32),
  "COL_36" VARCHAR2(64),
  "COL_37" NUMBER(20),
  "COL_38" NUMBER(20),
  CONSTRAINT "PK_T_MAIN" PRIMARY KEY ("COL_01"),
  CONSTRAINT "UK_T_MAIN_CODE" UNIQUE ("COL_07")
) COMPRESS FOR ARCHIVE REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0;

CREATE INDEX "SCHEMA_A"."IDX_COL_14" ON "SCHEMA_A"."T_MAIN" (
  "COL_14"
) GLOBAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_13" ON "SCHEMA_A"."T_MAIN" (
  "COL_13"
) GLOBAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_02" ON "SCHEMA_A"."T_MAIN" (
  "COL_02"
) GLOBAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_07_08" ON "SCHEMA_A"."T_MAIN" (
  UPPER("COL_07"),
  "COL_08"
) GLOBAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_02_16" ON "SCHEMA_A"."T_MAIN" (
    "COL_02",
    "COL_16"
  ) GLOBAL;

```

后续现场应急将表做了分区改造后，SQL 执行慢的现象消失。新表的表结构如下，按 COL_01 字段 hash 分区，该字段非业务 Where 条件字段，因此可以将访问通过 hash 的方式，打散到 4 个分区：

```sql
CREATE TABLE "T_MAIN" (
  "COL_01" NUMBER(20) CONSTRAINT "T_MAIN_OBNOTNULL_1779764441392384" NOT NULL ENABLE,
  "COL_02" NUMBER(20),
  "COL_03" NUMBER(20),
  "COL_04" VARCHAR2(3),
  "COL_05" VARCHAR2(6),
  "COL_06" VARCHAR2(64),
  "COL_07" VARCHAR2(256),
  "COL_08" VARCHAR2(512),
  "COL_09" VARCHAR2(16),
  "COL_10" VARCHAR2(8),
  "COL_11" NUMBER(20),
  "COL_12" VARCHAR2(256),
  "COL_13" NUMBER(10),
  "COL_14" VARCHAR2(256),
  "COL_15" NUMBER(20),
  "COL_16" VARCHAR2(3),
  "COL_17" VARCHAR2(1024),
  "COL_18" NUMBER(5),
  "COL_19" NUMBER(20),
  "COL_20" DATE,
  "COL_21" VARCHAR2(1),
  "COL_22" VARCHAR2(32),
  "COL_23" VARCHAR2(32),
  "COL_24" NUMBER(1),
  "COL_25" VARCHAR2(50),
  "COL_26" VARCHAR2(50),
  "COL_27" VARCHAR2(50),
  "COL_28" VARCHAR2(1),
  "COL_29" DATE,
  "COL_30" NUMBER(20),
  "COL_31" NUMBER(20),
  "COL_32" NUMBER(20),
  "COL_33" VARCHAR2(256),
  "COL_34" DATE,
  "COL_35" VARCHAR2(32),
  "COL_36" VARCHAR2(64),
  "COL_37" NUMBER(20),
  "COL_38" NUMBER(20),
  CONSTRAINT "PK_T_MAIN" PRIMARY KEY ("COL_01"),
  CONSTRAINT "UK_T_MAIN_CODE" UNIQUE ("COL_07")
) COMPRESS FOR ARCHIVE REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0
 PARTITION BY HASH(COL_01)
(PARTITION P_1,
 PARTITION P_2,
 PARTITION P_3,
 PARTITION P_4);

CREATE INDEX "SCHEMA_A"."IDX_COL_07_08" ON "SCHEMA_A"."T_MAIN" (
  UPPER("COL_07"),
  "COL_08"
) LOCAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_02" ON "SCHEMA_A"."T_MAIN" (
  "COL_02"
) LOCAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_13" ON "SCHEMA_A"."T_MAIN" (
  "COL_13"
) LOCAL;

CREATE INDEX "SCHEMA_A"."IDX_COL_14" ON "SCHEMA_A"."T_MAIN" (
  "COL_14"
) LOCAL;

```

## 关键诊断信息

### 触发条件

- 大量线程并发查询，可以通过 OCP 观察 TOP 执行 SQL。
 - 入参高度集中，访问单行或极少量行（RETURN_ROWS 较小）。
 - 存在索引回表。
 - 热点行缓存数据的引用计数基于 CAS 维护，存在 CAS 原子竞争。

### 事后诊断

在问题环境上用问题 SQL 压测复现：以 40 并发的文本协议测试，使 SQL 耗时范围为 5～20ms，查看表 Leader 30 节点上的 CPU 升高到 24%。

对应 40 并发的 perf 火焰图信息，可以看到 SQL 耗时主要集中在 kvcache 下的原子操作（atomic）相关函数上；对照 60 并发的 perf 信息，这两个函数的占比明显上升。

CPU 耗时主要在原子操作相关函数上，这些函数通过 CAS（Compare-And-Swap，比较并交换）原理维护引用计数。CAS 是由 CPU 硬件指令直接支持的无锁同步机制：任意时刻只有一个线程的 CAS 操作能够成功，其余线程需要重新读取并重试。当 N 个线程同时查询同一行缓存记录时，只有一个线程能成功，其余 N-1 个线程都在空转自旋，线程越多，空转越严重：

| 并发线程数 | 成功工作的线程 | 空转的线程 | CPU 有效吞吐占比 |
| --- | --- | --- | --- |
| 10 | 1 | 9 | ~10% |
| 50 | 1 | 49 | ~2% |
| 100 | 1 | 99 | ~1% |

此外，在 x86 环境上测试后复现：合并并 flush kvcache 后并发压测，也出现了走 kvcache + CAS 竞争的路径。

压测结果显示，40 并发下，x86 环境（64C）原子操作函数耗时占比约 6.86%，SQL 耗时 4～7ms（空库压测）；ARM 环境（192C）原子操作函数耗时占比约 14.59%，SQL 耗时 5～20ms。由此可见，该问题在 x86 和 ARM 两个架构下均有概率出现，ARM 环境下更易触发。

## 问题原因

集群从 x86 切换至 ARM 后，新主集群由主备切换形成，表数据稳定落在 SSTable 上，SQL 读取该表走 SSTable 单行读取路径。当业务以相同参数高频并发访问同一行（或极少量行）数据时，多个线程需要同时维护该行缓存数据的引用计数，而引用计数基于 CAS 无锁机制实现。高并发同一热点的场景下，CAS 重试导致大量线程 CPU 空转自旋，从而引发 CPU 打满的性能瓶颈。

**为什么切换前 x86 上没有出现该问题：**

- 在 x86 测试环境上可以复现该热点现象，说明 x86 场景下同样可能存在；同样 40 并发下，x86 环境 SQL 耗时更快，因此该问题在 x86 上较 ARM 更难触发。
 - 从原理角度看，随着时间推移，表数据在缓存中的分布会越来越分散（存在 DML 时，访问并发会分散到不同版本的数据缓存中），日常访问走多版本扫描路径，原子操作集中度低，也在一定程度上缓解了热点现象。

**为什么分区改造后问题消失：**

慢 SQL 上作为查询条件的两个字段都不是分区键，分区改造后查询被 hash 打散到 4 个分区上，分摊了查询流量，缓解了热点访问。

## 问题的风险及影响

SQL 读表走 SSTable 单行读取路径，业务并发高频使用同一条件，随着并发增长，高并发下出现 CAS 原子竞争，导致大量执行相同 SQL 的线程 CPU 空转自旋，继而出现 CPU 被打满，最终恶化为大量相同 SQL 排队、长时间无法执行完毕的情况。

## 影响租户

| sys | MySQL | Oracle |
| --- | --- | --- |
| YES | YES | YES |

## 影响版本

| 影响版本 | 修复版本 |
| --- | --- |
| OBServer 3.x | 4.3.5 及之后版本 |
| OBServer V4.2.x 及更早版本 | 4.3.5 及之后版本 |

## 解决方法

**应用侧开发规范建议：**

- 结果集缓存：建议业务侧检查是否存在入参一致的高频业务行为，并评估是否可以从业务层提前改造避免，或在前端利用结果缓存等类似机制，避免该场景下的压力直接释放给数据库侧。

**应用数据层语句优化建议：**

- 表分区改造：该场景问题通过分区表改造分散热点。注意不能通过 Where 条件字段分区，否则分区裁剪仍然会带来集中热点的问题，但这种方式本身可能带来访问效率的上升（访问多分区的额外开销与热点争用的权衡）。
 - 覆盖索引：对于可以建立覆盖索引的场景（本例 SQL 几乎涉及表全列，不适合该方案；适合 select 列较少的场景），通过避免回表的方式减少对 kvcache 的访问频率。

**数据库架构优化建议：**

- 升级至 4.3.5 及之后版本。

## 规避方式

同解决方法。

上一篇

[sys 租户归档一直显示 STOPPING](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006870877)

下一篇

[租户内存不足导致 allocate memory fail](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006739705) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线