慢查询SQL问题

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.5.0.0
【问题描述】obproxy_slow.log 中
2026-07-02 08:44:11.993244,hkodp,hkocb:yewu:maas-platform,OB_MYSQL,model_hourly_record,model_hourly_record,OB_MYSQL_COM_QUERY,INSERT,success,INSERT INTO model_hourly_record …,show_fiel,5477748us,0us,0us,5477748us,Y0-00007FDD5CFE0AE0,YB42AC1EC539-0006547ECA2A4610-0-0,172.30.197.60:55168,0,172.30.197.57:2881
总耗时 5s
排查：
通过 GV$OB_SQL_AUDIT 查询 相关时间

start_time svr_ip svr_port sql_id flt_trace_id trace_id tx_id elapsed_time execute_time queue_time PLAN_TYPE LOCK_FOR_READ_TIME NET_TIME NET_WAIT_TIME SCHEDULE_TIME DECODE_TIME GET_PLAN_TIME TOTAL_WAIT_TIME_MICRO ret_code
2/7/2026 08:44:06.517033 172.30.197.57 2882 FBB45EDDFEBB6AB090A5917F325A642C 00065596-1b50-a8ec-6ae9-9e418f004697 YB42AC1EC539-0006547ECA2A4610-0-0 1238493269 5474035 2163 217 1 0 0 2 0 0 729 0 0

在此关系中没有看到耗时长的。

image
image1132×319 41.5 KB

obdiag 分析

image
image877×771 121 KB

我想定位到底是哪一步比较耗时
@论坛小助手

2 个赞
#3

根据您的描述，您在OceanBase 4.5.0.0版本的生产环境中遇到了慢查询的问题。尽管通过GV$OB_SQL_AUDIT以及obdiag初步分析后没有发现明显耗时的操作步骤，但为了更深入地定位导致SQL执行缓慢的原因，我们可以使用obdiag工具进行进一步的日志采集与分析。

日志采集场景: SQL性能问题

日志采集命令:

obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h<your_host> -P<your_port> -u<your_username>@<your_tenant> -p<your_password> -D<your_database>', trace_id='<your_trace_id>'}"

请将<your_host>, <your_port>, <your_username>, <your_tenant>, <your_password>, 和 <your_database>替换成实际连接数据库需要的信息，并用具体的trace id替换<your_trace_id>部分。此命令可以帮助我们收集更多关于特定SQL执行过程中的详细信息，包括但不限于执行计划、等待事件等，从而有助于识别瓶颈所在。

提供更多信息以助于诊断：

  1. 您能否分享一下具体发生慢查询的SQL语句？这将帮助我们直接针对该查询进行分析。
  2. 发生慢查询时，整个集群的负载情况如何（例如CPU利用率、内存使用量）？了解这些背景信息有助于判断是否为资源竞争引起的问题。
  3. 是否有对表结构或索引近期做出过更改？有时候这类变更可能会意外地影响到现有查询的性能。
  4. 能否告知是否有设置任何特定的参数值，比如优化器相关设置，或者存在其他可能影响SQL执行效率的因素？

完成上述日志采集后，请将得到的日志文件打包并发送给我们，以便我们能够基于详细的日志数据来进行更深层次的原因排查。希望这些步骤能帮到您解决问题。如果您有任何疑问或需要进一步的帮助，请随时告知。

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

2 个赞
#4

这个问题涉及到TIME和OB的平衡，根据我的经验，适当调整time会有帮助。

2 个赞
#5

指的是 slow_query_time_threshold 吗？

2 个赞
#6

obdiag gather plan_monitor --trace_id YB420BA2D99B-0005EBBFC45D5A00-0-0
–env host=xx.xx.xx.xx --env port=2881 --env user=root@test --env password=*** --env database=test
https://www.oceanbase.com/docs/common-obdiag-cn-1000000006175714
使用obdiag收集一下信息

2 个赞
#7

没查到 :upside_down_face:，是不是被覆盖了
obdiag gather plan_monitor --trace_id YB42AC1EC539-0006547ECA2A4610-0-0 --env host=xxx --env port=2881 --env user=root@test --env password=xxx --env database=xxx

[ERROR] The data queried with the specified trace_id YB42AC1EC539-0006547ECA2A4610-0-0 from gv$ob_sql_audit is empty. Please verify if this trace_id has expired.
我直接去服务器上查也没有
[root@hkocb-57 log]# grep YB42AC1EC539-0006547ECA2A4610-0-0 *.log
[root@hkocb-57 log]# pwd
/opt/oceanbase/oceanbase/log

2 个赞
#8

估计是覆盖了 看看能否复现

1 个赞
#9

666