集群升级到 V4.3.5 版本后，因存储层估行结果偏大，执行计划跳变，CPU 打满

问题现象

基于索引的范围查询，表的数据量大，而查询的 range 较小，可能出现存储层估行结果偏大，导致计划走偏，影响查询性能。

场景举例（为方便描述起见，假设 t1 表只有一个 major sstable，总共有 100w 行，平均分布在 2000 个微块上（每个微块 500 行），且 [1, 100] 在一个微块上）。

• case1： c1 为普通索引，c1 在 [1, 100] 上每个值各命中一行。

  -- 实际行数为 1，估行结果为 500
  SELECT * FROM t1 WHERE c1 = 100; 
  -- 实际行数为 3，估行结果为 500
  SELECT * FROM t1 WHERE c1 in (1, 10, 100); 
  -- 实际行数为 89，估行结果为 500
  SELECT * FROM t1 WHERE c1 > 10 and c1 < 100; 
  

• case2： c1 为唯一索引。

  -- 实际行数为 89，估行结果为 500
  SELECT * FROM t1 WHERE c1 > 10 and c1 < 100;
  

目前来看，对于 OceanBase 数据库 V4.3.5 以及 V4.3.5 GA Hotfix1 ~ Hotfix4 版本，只要看到查询计划中估行结果严重偏离预期，那么基本上就是踩中了该问题，可升级到 V4.3.5 Hotfix5 及之后版本进行修复。

关键诊断信息

触发条件

基于索引的范围查询，表的数据量大，而查询的 range 较小。

事前巡检

查看查询计划中的估行字段 EST.ROWS 的值是否符合预期。

事后诊断

估行的结果与预期的相比，偏差不在一个数量级则说明已踩中该问题。

问题原因

估算 range 左边界微块行数对 range 内总行数的影响程度时，excluded_row_count 偏小，导致估算的影响程度偏低，就不会打开左边界的微块精确获取行数，而是直接将左边界微块的总行数全部算在 range 行数估算内，往往就导致估行结果偏大。

问题的风险及影响

物理计划走偏，影响查询性能。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版 V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.3.5 GA Hotfix5（oceanbase-4.3.5.0-100050012025022422）、V4.3.5 GA Hotfix6（oceanbase-4.3.5.0-100060022025031922）、V4.3.5 GA Hotfix7（oceanbase-4.3.5.0-100070012025040810）、V4.3.5 GA Hotfix8（oceanbase-4.3.5.0-100080012025052715）、V4.3.5 GA Hotfix9（oceanbase-4.3.5.0-100090012025063017）、V4.3.5 GA Hotfix10（oceanbase-4.3.5.0-100100032025071516）、V4.3.5 GA Hotfix11（oceanbase-4.3.5.0-100110012025072810）、V4.3.5 GA Hotfix12（oceanbase-4.3.5.0-100120012026011215）、V4.3.5 BP1（oceanbase-4.3.5.1-101000292025030623）。

• 手动绑定正确的计划。

规避方式

手动绑定正确的计划，如添加 Hint 或者使用 OUTLINE 进行绑定。