事前巡检
该问题触发与执行计划及业务数据分布有关系, 不太好直接事前巡检。
事后诊断
业务租户 CPU 飙高，并且在 pstack 中存在大量等锁的信息，内容如下。
#0 0x000055e8714db976 in oceanbase::common::ObLatchMutex::try_lock(unsigned int, unsigned int const*) from /home/admin/oceanbase/bin/observer
#1 0x000055e8716e140a in oceanbase::sql::ObTenantSqlMemoryManager::calculate_global_bound_size_by_interval_info(oceanbase::common::ObIAllocator&, long, bool) from /home/admin/oceanbase/bin/observer
#2 0x000055e87876e75d in oceanbase::sql::ObTenantSqlMemoryManager::calculate_global_bound_size(oceanbase::common::ObIAllocator*, bool) from /home/admin/oceanbase/bin/observer
问题现象
现象是业务租户 CPU 很高，请求执行变慢，并且 pstack 可以看到很多线程在 calculate_global_bound_size_by_interval_info 调用路径等锁。
问题原因
下面这个计划，subplan filter 右支有个 hash join，并且 hash join 涉及的行数较少，这样 subplan filter 左边每行数据，rescan 后会频繁触发 hash join 算子重新调用自动内存管理的 calculate_global_bound_size_by_interval_info 接口(会有加锁操作)， 这种情况该接口单 query 请求内调用频率很高，并且有大量这种请求同时并发执行时，会加大锁冲突，导致业务请求变慢，租户CPU升高。
触发条件如下：
SQL 需要生成类似上面这种计划，
subplan filter右侧是hash join。subplan filter右侧hash join处理数据量比较小。该类 SQL 计划本身业务很多请求并发执行。
问题的风险及影响
遇到该问题，租户 CPU 可能打满，会导致业务请求 RT 飙高，影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户。
影响的版本
OceanBase 数据库社区版 V4.2.1_CE_BP2（oceanbase-ce-4.2.1.2-102000042023120514）及之前版本。
OceanBase 数据库企业版 V3.1.2 BP11（oceanbase-3.1.2-111000052023010412）及之前版本、V3.2.3 BP10（oceanbase-3.2.3.3-110000092023091219）及之前版本、V3.2.4 BP7（oceanbase-3.2.4.7-107000012023113010）及之前版本、V4.1.0 BP4（oceanbase-4.1.0.2-104000032023092119）及之前版本、V4.2.1 BP2（oceanbase-4.2.1.2-102010012023120119）及之前版本。
解决方法
解决方法：
升级至问题已修复版本,目前已修复如下版本:
OceanBase 数据库社区版 V4.2.1_CE_BP2（oceanbase-ce-4.2.1.2-102000042023120514）之后版本。
OceanBase 数据库企业版 V4.2.1 BP3（oceanbase-4.2.1.3-103000052023122809）及之后版本。
发现问题 SQL，分析通过绑定 hint 方式规避上述特征的执行计划。
协调降低该类 SQL 请求并发。
规避方式：
暂时有问题版本, 没有特别好的规避方式。
