同样的sql在oceanbase与mysql执行速度有差异

OceanBase 技术问题
,
#1

【 使用环境 】 测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.4.0
【问题描述】在oceanbase上执行sql出现OBServer wait时间过长
【复现路径】执行sql
【附件及日志】
sql语句
执行的sql语句.txt (71.6 KB)

sql执行的日志

[14:28:29]ODC 解析 SQL(746 us)
[14:28:29]SQL 预检查(48 us)
[14:28:29]DB Permission Check(8 us)
[14:28:29]External SQL interception(8 us)
[14:28:29]SQL Console Rule Check(6 us)
[14:28:29]SQL Check(4 us)
[14:28:29]执行(8.9 s)
[14:28:29]Jdbc prepare(2 ms)
[14:28:29]Network consumption(7.03 ms)
[14:28:29]OBServer wait(8.66 s)
[14:28:37]DB Server Execute SQL(157.21 ms)
[14:28:38]Calculate duration(69.48 ms)
[14:28:38]Get result-set(244 us)
[14:28:38]获取 SQL 类型(819 us)
[14:28:38]获取可编辑信息(9 us)
[14:28:38]获取列信息(3.69 ms)
[14:28:38]获取告警内容(4 us)
[14:28:38]SQL 后置检查(93 us)
[14:28:38]SQL Console Rule Check(13 us)
[14:28:38]Set Nls Format(3 us)
[14:28:38]Data Masking(55 us)

sql执行计划.txt (1.2 MB)

请问 OBServer wait(8.66 s)为什么出现这么长的时间，应该如何配置解决这个问题

1 个赞
#3

看执行计划，除第一次时间久点后面都是一百多毫秒级完成的。不慢呀

#4

但是 OBServer wait(8.66 s)等待时间有点长，可以通过什么机制，减少这个等待时间吗，还有就是 OBServer wait(8.66 s）这个是什么意思？可以解释下吗 文档上没找到

#5

为什么第一次比较慢，后面就变快了呢

#6

首次执行是硬解析需要解析sql生成一些执行计划，通常会慢点，后面就会直接命中计划执行sql了。

#7

那意思就是 OBServer wait(8.66 s) 这个解析sql生成一些执行计划等待的时间，可以这样理解吗？
还有就是，同样的sql放在mysql8.0下执行，速度比ob快1倍左右

#8

我们这里耗费了8秒，是不是跟硬件有关系，还是配置的哪里有问题，怎么提高解析sql的时间，谢谢

#9

除非第一次外 后续执行也是比mysql慢么，存在算子NESTED-LOOP JOIN，你的集群架构是啥样的，租户优先级是随机分布么

#10

第一次慢，后续执行比mysql块，但是查询的条件会发生变化，比如多几个参数 少几个参数

#11

image
image3088×1784 390 KB

集群机构如图，优先分配租户zone1

#12

执行计划是参数化存储在PlanCache中。多几个参数 少几个参数相当于会产生新的执行计划。
使用obdiag也收集一下
SQL性能问题, 此处env中的trace_id对应gv$ob_sql_audit的trace_id
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”
执行全链路诊断 收集一下信息
○ 开启会话窗口。
○ set session ob_enable_show_trace = on;
○ 执行sql
○ show trace

#13

安装文档安装obdialog后
执行

obdiag config -h 10.1.250.157 -uroot@neo_dev  -p'DevOps00!@#' -P2881

出现异常

[ERROR] command failed. Please contact OceanBase community. e: (1146, "Table 'oceanbase.dba_ob_servers' doesn't exist")
Trace ID: d5e15b02-a716-11ef-b63e-246e9612af44
If you want to view detailed obdiag logs, please run: obdiag display-trace d5e15b02-a716-11ef-b63e-246e9612af44
[root@dev4 ~]# obdiag display-trace d5e15b02-a716-11ef-b63e-246e9612af44
[2024-11-20 16:09:59.121] [DEBUG] - cmd: obdiag config
[2024-11-20 16:09:59.122] [DEBUG] - opts: {'inner_config': None, 'h': '10.1.250.157', 'u': 'root@neo_dev', 'p': 'DevOps00!@#', 'P': '2881'}
[2024-11-20 16:09:59.122] [DEBUG] - mkdir /usr/local/oceanbase-diagnostic-tool/conf/inner_config.yml
[2024-11-20 16:09:59.126] [DEBUG] - mkdir /root/.obdiag/config.yml
[2024-11-20 16:09:59.130] [DEBUG] - Getting all the node information of the cluster, please wait a moment ...
[2024-11-20 16:09:59.130] [DEBUG] - get observer version, by sql
[2024-11-20 16:09:59.130] [DEBUG] - start get_observer_version_by_sql . input: 10.1.250.157:2881
[2024-11-20 16:09:59.132] [DEBUG] - connect databse ...
[2024-11-20 16:09:59.133] [DEBUG] - get_observer_version_by_sql ob_version_info is ('5.7.25-OceanBase_CE-v4.3.4.0',)
[2024-11-20 16:09:59.135] [DEBUG] - connect databse ...
[2024-11-20 16:09:59.137] [ERROR] command failed. Please contact OceanBase community. e: (1146, "Table 'oceanbase.dba_ob_servers' doesn't exist")
[2024-11-20 16:09:59.137] [INFO] Trace ID: d5e15b02-a716-11ef-b63e-246e9612af44
[2024-11-20 16:09:59.137] [INFO] If you want to view detailed obdiag logs, please run: obdiag display-trace d5e15b02-a716-11ef-b63e-246e9612af44

请问这个如何解决，谢谢

#14

把连接串配置改成root@sys的 DBA视图是sys租户的

#15

obdiag_gather_pack_20241121110515.zip (405.7 KB)
这是使用obdiag 生成的文件，麻烦帮忙看下，为什么OBServer wait(8.66 s)时间，谢谢，辛苦

#16

看结果，第一次执行时确实大部分时间时花在解析上了呢

image
image2846×690 21.7 KB

消耗时间为9.2s，解析花了7.5s，另外第一个执行的参数有什么不同吗，中间有没有合并，看起来第一次的ssstore read要高很多

#17

复杂的大的sql，第一次查询速度慢，同样的sql，机器配置一样，跟mysql查询相比差距在30倍左右，但是第一次查询之后，速度跟mysql，基本上一致
我的问题是，如何解决第一次查询的速度提升，因为sql是动态的，条件变了，速度跟首次查询一样，这个有点不能接受，有什么方法解决吗，还是我搭建的集群配置的有问题
谢谢，辛苦

#18

如果是像前面案例看到是那样，是因为第一次执行时SQL解析消耗了太多的时间，那只能通过增大plan_cache的大小，减少执行计划的淘汰概率，从而减少硬解析的次数了，可以观察一下同一个SQL的执行计划的plan_id和plan_hash会不会变化很频繁，如果很频繁就说明执行计划淘汰的次数比较多，淘汰之后都是需要硬解析的

#19

我有下面的几个问题
1、如何增大plan_cache的大小？
2、硬解析这个时间真的太长了，mysql就很短，这个后续有计划提升吗？
谢谢，辛苦

#20

1、可以调整ob_plan_cache_percentage变量的值
参考https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001576572
set global ob_plan_cache_percentage=xxx;
2、这个解析时间属于优化器的范畴，只有官方的研发老师可以回答你了

#21

建议可以优化一下sql查询条件，尽量使用同一条sql避免生成新执行计划
硬解析问题这边咨询下sql组相关同学。