OB 执行计划突然出现变动，导致执行效率较慢

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】oceanbase 4.3.5 bp2
【 使用版本 】4.3.5.2-102010012025052715
【问题描述】OB 执行计划突然出现变动，导致执行效率较慢
1、昨天我们发现系统突然频繁告警，告警内容多为CPU使用率过高

image
image2114×1084 406 KB

2、从TOP SQL中定位到相应SQL ,SQL本身比较简单，为单表查询。

SELECT
  org_id_ AS orgId,
 ... ...
  IFNULL(
    SUM(IF(order_direction_ = ?, basic_measure_num_, ?)),
    ?
  ) AS basicOutNum
FROM
  bfip_inventory_account
WHERE
  org_id_ = ?  AND business_date_ >= ?   AND business_date_ <= ?   AND chxx_id_ = ?
  AND repository_id_ = ?   AND order_type_ = ?   AND enable_auto_estimate_ = ?
  AND order_type_ IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
GROUP BY   chxx_id_,   repository_id_

3、由于该SQL为超高频SQL，其实我们为该SQL创建对应的索引，索引结构也比较简单就是覆盖各个查询字段的普通索引。

image
image1075×532 44.5 KB

4、从OCP的SQL诊断，我们发现，该SQL会时不时出现走错执行计划的问题。

image
image2193×1184 301 KB

5、我们想问问，为什么会出现这类的现象呢？后续是否有规避的方案，
我们看了一下文档，感觉相关性比较高的原因好像只有“动态采样”才会引起执行计划突然的一些变化。

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

2 个赞
#3

针对您提到的“OceanBase 4.3.5 BP2 版本中，某高频SQL的执行计划突然变动，导致执行效率降低”的问题，我们可以通过使用 obdiag 工具来收集SQL性能相关的日志，同时针对SQL执行计划变更的情况进行根因分析。以下是具体的命令和步骤：

日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

上述命令中，请替换 -h127.0.0.1 -P2881 -utest@test -p****** -Dtest 为您的实际数据库连接信息，trace_id 参数为您希望追踪的具体SQL语句的跟踪ID。这一步是为了收集与SQL性能相关的所有日志，包括但不限于执行计划的变化情况、资源使用情况等。

另外，为了更有效地定位和解决问题，在此需要您提供一些额外的信息：

  1. 变动前后SQL的具体执行计划是什么样的？可以尝试在不同时间点使用 EXPLAIN 查看并对比SQL的执行计划。
  2. 在执行计划变化之前，是否进行了任何系统维护操作或数据库参数调整？
  3. 该SQL的执行频率有多高？每次执行的大致耗时是多少？
  4. 系统中是否有其他SQL也出现了类似的性能下降情况？

请您按照上述指导收集相关信息，并将收集到的日志文件和答案提供给我们，我们将根据这些信息进一步分析问题的原因，并给出相应的解决方案。感谢您的配合。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

你这明显是大小账号问题吧？TP场景，这种别说OB，在数据库层面就很难解，只是不同数据库能解的程度不一样，即便是传说中的SPM也要看运气。看下如果业务允许的情况下绑定一下hint或者outline，都是比较麻烦的解法。

#5

666

#6

嗯嗯，我理解，主要是SQL实际上是很简单的单表查询。如果复杂查询我觉得是正常。

其实我觉得有点不应该。而且，这个SQL，这个索引是专门针对这个SQL进行处理的。其他索引的结构其实差异很大。这种情况我还是觉得不应该。

#7

–根据时间和执行语句查询trace_id
select query_sql,svr_ip,TRACE_ID,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT
WHERE REQUEST_TIME>=‘2024-04-05 14:34:00’ and lower(query_sql) like ‘%select%’;
根据obdiag收集一下 sql_monitor信息
obdiag gather plan_monitor --trace_id YB420BA2D99B-0005EBBFC45D5A00-0-0 --env"{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’}"

#8

超高频感觉还是要绑hint

#9

试一试 * 绑定执行计划：通过 CREATE OUTLINE 语句对目标 SQL 绑定计划。

#10

6666