为什么streamingresult的执行效率比 cursor fetch的执行效率高?底层实现上有什么不同呢。

https://docs.pingcap.com/zh/tidb/stable/java-app-best-practices/#使用-streamingresult-流式获取执行结果

cursor fetch:客户端发起一次请求(要N条记录),server收到请求后返回N条记录给客户端,然后自己保存当前状态,客户端完成后再次请求N条记录,server发现还是这个连接和相同stmtid过来的,那么根据之前保存的状态继续传给客户端N条记录,如此一来客户端和server一直交互而且每次传输的数据量也不多,导致效率较慢。但是在返回记录数比较少的时候性能也不差,因为没有那么多网络交互,又因为可以在应用程序多线程同时复用一个连接,可能会在小数据集上更加高效。
因此流式更适合处理结果集较大的场景,cursor fetch(大于0)适合处理高并发,连接复用,结果集较小的场景。

streamingresult的执行效率并不一定比 cursor fetch的执行效率高,
只是大结果集情况下,streamingresult可以通过流式的方式获取数据,不需要先将数据全部取出,同时能够在获取数据的同时进行处理和分析,Cursor Fetch 要一次性将所有数据取出,没有 StreamingResult 灵活,对数据库的内存造成的压力也比较大,streamingresult比Cursor Fetch 更适合;
小结果集情况下,Cursor Fetch 则可以避免数据流式传送所带来的延迟,反而是一次性将数据全部取出效率更高。

那流式读取不也是要设置fetchsize,min_value吗,我理解也是分批次返回给客户端的,这两种方法都要分批,为啥流式读取就会好些?

你的意思是流式读取是边发边取,而cursor fetch是先要查到所有数据然后再分批次返回吗,暂未返回的数据是存在内存里吗?

是的,

Cursor fetch size大于0,并不是一次性查询所有结果寄存起来,获取到需要的记录后,算子全部堵塞,下次请求过来继续执行。

流式不分批,数据库端一直往网络里面塞数据直到完成。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。