向量检索查询耗时不稳定原因排查及如何优化查询性能

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.5.3
【问题描述】
向量检索查询耗时不稳定原因排查及如何优化查询性能
【复现路径】
【附件及日志】
表结构：
CREATE TABLE data_detail (
id bigint not null auto_increment COMMENT ‘自增主键’,
scene_url varchar(500) not null COMMENT ‘图片链接’,
shot_time datetime not null COMMENT ‘拍摄时间’,
device_id varchar(255) not null COMMENT ‘设备ID’,
person_count bigint not null COMMENT ‘人员数量’,
relation_id varchar(500) default null COMMENT ‘目标ID’,
obj_id varchar(500) default null COMMENT ‘追踪ID’,
target_type varchar(100) default null COMMENT ‘目标类型’,
x1 int default null COMMENT ‘边界框左上角的x坐标’,
y1 int default null COMMENT ‘边界框左上角的y坐标’,
x2 int default null COMMENT ‘边界框右下角的x坐标’,
y2 int default null COMMENT ‘边界框右下角的y坐标’,
reid_embedding VECTOR(512) default null COMMENT ‘reid向量’,
align_embedding VECTOR(768) default null COMMENT ‘对齐向量’,
create_time datetime not null COMMENT ‘创建时间’,
PRIMARY KEY (id),
index idx_shot_time_device_id_target_type (shot_time, device_id, target_type),
VECTOR INDEX idx_reid_embedding (reid_embedding) WITH (distance=cosine, type=hnsw, lib=vsag),
VECTOR INDEX idx_align_embedding (align_embedding) WITH (distance=cosine, type=hnsw, lib=vsag)
)
查询语句：
SELECT t.id as id, t.scene_url as sceneUrl, t.shot_time as timestamp, t.device_id as deviceId, t.person_count as personCount, t.obj_id as objId, t.target_type as type, t.x1, t.y1, t.x2, t.y2, cosine_distance(t.reid_embedding, ?) AS simi FROM dw_1998913224163164160 as t WHERE t.reid_embedding is not null and t.shot_time >= ? and t.shot_time <= ? and t.target_type = ? ORDER BY simi APPROXIMATE LIMIT ?
执行计划

wechat_2026-03-03_101839_172
wechat_2026-03-03_101839_172974×179 11.4 KB

查询耗时：
oot@user-pc:/home/dev/logs/data# cat info.log | grep selectPageResultsTopK
2026-03-03 09:09:37.552 [http-nio-18080-exec-1] INFO c.d.c.s.i.DataWarehouseServiceImpl - [queryByTopK,210] - queryByTopK, selectPageResultsTopK, cost: 543ms, traceId: 2028638892886827008
2026-03-03 09:15:14.977 [http-nio-18080-exec-3] INFO c.d.c.s.i.DataWarehouseServiceImpl - [queryByTopK,210] - queryByTopK, selectPageResultsTopK, cost: 125ms, traceId: 2028640309903073280
2026-03-03 09:15:22.265 [http-nio-18080-exec-4] INFO c.d.c.s.i.DataWarehouseServiceImpl - [queryByTopK,210] - queryByTopK, selectPageResultsTopK, cost: 16ms, traceId: 2028640340924145664
2026-03-03 09:15:25.302 [http-nio-18080-exec-5] INFO c.d.c.s.i.DataWarehouseServiceImpl - [queryByTopK,210] - queryByTopK, selectPageResultsTopK, cost: 15ms, traceId: 2028640353670635520

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

1 个赞
#3

根据您的描述，您在使用 OceanBase 4.3.5.3 版本时遇到了向量检索查询性能不稳定的问题。这种情况下，可以利用 obdiag 工具来收集相关信息并进行初步的性能分析。具体步骤如下：

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

请您使用上述命令采集有关 SQL 性能问题的日志，并将生成的日志文件提供给我们。这将有助于我们分析为什么您的向量检索查询会存在性能不稳定的情况。

为了更准确地定位和解决您的问题，请您进一步提供以下信息：

  1. 您所使用的查询语句的具体内容是什么？
  2. 查询时所涉及的时间范围和目标类型的详细定义是什么样的？
  3. 能否提供一下该表的创建语句（CREATE TABLE）以及向量索引的创建语句（CREATE INDEX）？
  4. 当前的系统配置（如硬件配置、OceanBase 集群配置等）是怎样的？
  5. 在执行性能较差的查询时，是否有其他大量并发操作正在进行？
  6. 您是否已经尝试过调整任何与查询性能相关的参数？如果有，调整了哪些参数，调整前后性能有何变化？

通过以上信息，我们可以更全面地了解您的问题背景，从而提供更有效的解决方案。

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

#4

是否仅首次或前两次的sql慢。怀疑为索引冷加载导致

#5

从现象上看是这样。 如何进行索引热加载。之前有试过服务启动的时候，随机生成向量进行一次检索，但效果也达不到预期。更换检索条件查询速度也会变慢

#6

可以可以

#7

试一下预热查询呢
– 应用启动时执行预热查询，触发向量索引加载到内存

SELECT id, cosine_distance(reid_embedding, ‘<任意512维向量>’) AS simi

FROM dw_1998913224163164160

WHERE reid_embedding IS NOT NULL

ORDER BY simi APPROXIMATE LIMIT 1;

#8

这种方法之前也有试过，请问是否还有其他方案。另外想咨询下如果想实现每天亿级向量的实时灌库和检索，能支持吗，延迟是什么样的，是否有压测性能数据

#9

向量索引是个整体. 加载起来后就是整个索引一起加载到内存了.不会由于改变过滤条件后又需要加载的情况，扩容一下索引内存大小试试
– 查看当前向量内存配置
SHOW PARAMETERS LIKE ‘%vector_memory%’;
– 根据数据量调整（百分比为租户内存的占比）
ALTER SYSTEM SET ob_vector_memory_limit_percentage = XX;

#10

了解了，感谢回复

#11

目前问题还存在么

#12

:+1: :+1: :+1: :+1: :+1: :+1: