简单的根据住建查询clob字段特别慢

OceanBase 技术问题
#1

oceanbasev4.2.5.5版本

问题现象：
select clob字段 from table where 主键id = xxxxxxx ;
odc执行发现特别慢要11秒 ， 查看执行计划就是一个 table get 主键定位 ， 在看执行记录去分析发现执行要12s ， Jdbc preparea就要 11.5s

针对以上有如下两个问题 ：

1、odc上面显示的jdbc preparea主要是做什么的
2、为什么会出现此现象

#3

@张雨齐

#4

还有个get result特别慢

#5

我没有使用过ODC，但是大概看过ODC，也是java实现的一个web或者客户端工具，还是java那一套sql执行逻辑。提供一个ODC版本，看看是不是最新版的。

不是得话，更新一下ODC。

历史版本中也存在类似性能问题修复记录：

ODC V4.1.1 修复了“SQL 执行时查询 SQL 执行时间慢”等问题
ODC V4.1.1

并且 ODC V4.2.2 已升级 JDBC 组件至 2.4.7.1，暗示早期版本可能存在驱动性能缺陷。

ODC V4.2.2-BP

#6

好深奥的问题，学习一下

#7

想请教下 odc上面的执行时间包含几部分内容
有两部分不太理解

一个是jdbc prepare
一个是get result-set

这两部分是做什么的呢。和oceanbasse驱动有关系么

#8

指的是 JDBC PreparedStatement么
麻烦截图看一下

#9

写过JDBC代码吗？

PreparedStatement ps = conn.prepareStatement(sql);
ps.setFetchSize(10); // 分批获取结果
ResultSet rs = ps.executeQuery();
while (rs.next())

conn.prepareStatement(sql);这部分就是把sql发给数据库，但是还不知道，预编译阶段，数据库会把这个sql缓存下来，解析好语法树。后续在有相同sql，数据库就不需要解析sql了。

ResultSet rs = ps.executeQuery();这个就是执行sql，对于dml就是真实执行了，返回就拿到了影响行数。查询就不是你看到的结果集。
while (rs.next()) 这部分就是你说的get result-set

#10

还有个问题 如果是io问题导致变慢有什么系统表能追溯到么 ， 根据trace_id查看v$ob_sql_audit发现最近执行的一次记录也没有 ，根据内存分配也不太可能刚执行的一条sql在审计表里面也查不到啊。

enable_sql_audit是开启的 ， 架构模式是random集群模式

1、如果是io过高导致的时间异常是否有相关的系统表能追溯到具体信息
2、为什么v$ob_sql_audit查看不到最近的一次执行sql ， enable_sql_audit是开启的 ， memory足够

#11

这部分慢和数据库驱动有关系？oceanbase驱动？

#13

jdbc只是定义的标准么，驱动才是具体的实现。没问题吧 ，
这俩部分慢要么就是驱动的关系要么就是io的关系？

#14

和驱动没太大关系啊。
在使用 OceanBase 数据库时，JDBC 驱动（OceanBase Connector/J） 是 Java 应用与数据库之间的桥梁。它不仅实现了标准 JDBC API，还针对 OceanBase 的协议进行了深度适配，尤其在 PreparedStatement 执行过程中扮演着至关重要的角色。

驱动只是一种标准协议去和数据库交互，不会有什么耗时的过程。

你还是看看ODC版本，或者用其他工具看看是不是也慢

#15

所有工具都慢 用dbeaver也慢。所以才怀疑是驱动的问题或者io的问题

但是io我们看了应用是没有io异常消耗的 ，想看数据库服务器但是没权限 ， 所以想问下有哪些系统表可以追溯是io的问题

#16

交互的过程 有大文本频繁获取（读写）会不会有io消耗？

#17

IO问题，只能去ob里找慢sql。

去ocp上慢SQL看看有没有

#18

没有慢sql。 只有jdbc prepare. 和 get result-set比较慢

#19

麻烦截个图呗。或者做个全链路分析

#20 
SELECT ROUND(AVG(LENGTH(clob_column)) /1024,2) AS byte_length
FROM your_table
WHERE id = 1;

改成你的表名的sql，查询clob字段是多大，如果太大也是比较慢