流式查询出现Out Of Memory Quota

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.3.0
【复现路径】对大表(1亿+)进行查询,使用下述流式查询


但数据库还是出现了 Out Of Memory Quota![conn_id=94979]问题
mem-quota-query设置的1G
想请教各位大佬,是因为 使用流式查询是只减少了数据库服务器向客户端一次返回的记录数,在数据库服务器端还是一次性把所有数据都查询出来了,查出来的数据超过了1G,导致的吗?

贴下你的语句和执行计划
服务端肯定不会一次性把所有的数据全部查出来的

执行的sql及计划:

顺便贴下代码中流写法:

jdbc的url上有开启游标查询吗?
加useServerPrepStmts=true&useCursorFetch=true

加了也不好用

还是 Out Of Memory Quota

1.加个索引吧
2.SET tidb_distsql_scan_concurrency = 2; 这样可以让语句用的内存少一点

但是建议加索引

全表扫就加索引,二级索引回表查。
好像也没有太好的办法。
监控中看看是不是这个SQL占了内存

sql里面用了2个order by,又全表扫描,把整个表的数据都拉tidb server上去排序了。自然就容易oom拉。
首先看看project_id是不是可以过滤很多数据,建个索引。

实际场景下project_id基本过滤不掉数据,那我理解就是因为数据量太大了,都放到tidb server上排序所以OOM了吗?

看监控了这个SQL确实很占内存,就是因为是大数据查询所以用了这种游标的写法,但是没想到OOM了

流式查询和普通查询对tidb来说占用的内存是一样的吗?

我理解流式查询应该是一部分一部分去查询的,应该和普通查询一下子都查出来 不一样吧?

你把order by去掉试试。
我的理解是因为有order by导致用不了流式。 不把数据全部排序完不知道那条应该在前面返回。

理论上流式查询占用的内存会小一点,但是性能会差一点

还有一种方式就是将mem-quota-query值调大,这个配置应该主要是为了保证tp业务性能的,你这个查询很明显不是tp业务了,应该是ap业务,可以适当调大这个参数。

我觉得也是,就是因为这个排序,把所有数据都加载到了tidb server 中导致了单条查询大于1G。我尝试着加了patientid 和 visitid的索引就可以了

我觉得加上project_id,patientid,visitid三列联合索引才行吧,光加后面两列就可以吗?

没加projectId,因为当前情况下projectId不会过滤多少数据

赞同,虽然过滤不了多少数据,但是可以用索引的有序性来减少再次排序