【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】OB
【 使用版本 】V4
【问题描述】业务应用没有发布新版本，但数据库中某条核心SQL的执行计划突然变差（如索引选择错误），导致查询响应时间显著增加，CPU使用率飙升。
1 个赞
看下是否是因为表的行数变化导致，可以收到收集一下相关表执行计划
对比下前后执行计划 耗时在哪里。
2 个赞
诊断命令：
首先，你可以通过以下命令定位消耗资源最多的SQL，并初步判断其执行计划是否存在异常。
sql
– 查询特定租户下消耗CPU最多的TOP SQL:cite[9]
SELECT sql_id,
avg(execute_time) avg_exec_time,
count(*) cnt,
avg(execute_time - TOTAL_WAIT_TIME_MICRO) cpu_time,
RETRY_CNT, QUEUE_TIME, IS_HIT_PLAN
FROM OCEANBASE.V$OB_SQL_AUDIT
WHERE tenant_id = 你的租户ID
GROUP BY 1
ORDER BY (avg_exec_time * cnt) DESC
LIMIT 5;
说明：如果 IS_HIT_PLAN 字段为0，表示该SQL没有命中执行计划缓存；QUEUE_TIME 过大则可能表示CPU资源不足。
解决方案：
紧急恢复：最快速的方法是清空当前错误的执行计划缓存，强制SQL在下一次执行时重新进行硬解析以生成新计划。
sql
– 清空指定租户的计划缓存（请根据情况选择执行范围）
ALTER SYSTEM FLUSH PLAN CACHE TENANT = ‘你的租户名’;
彻底根治：如果问题反复出现，说明优化器可能无法稳定选择最优计划。此时，需要通过Outline将正确的执行计划（例如，强制使用某个索引）绑定到该SQL上。
sql
– 绑定SQL走指定的索引
CREATE OUTLINE bind_correct_plan ON SELECT/+ index(表名 索引名)/ * FROM 表名 WHERE …;
绑定后，可以通过查询 gv$outline 和 gv$plan_cache_plan_stat 来确认Outline是否生效。
希望这些基于真实场景和社区反馈的案例能帮助你更好地运维OceanBase数据库。如果你在处理特定类型的故障（例如网络抖动导致的切主或监控异常）时需要更具体的命令，可以随时提出。
1 个赞
多谢~
thanks