深度分页CPU打满

【详述】深度分页操作导致集群 BE 节点 CPU 几乎都打满，JDBC SQL 无论是 LIMIT 方式还是 JDBC ResultSet 方式都一样，而且 ResultSet 还容易把服务 JVM 打爆
【背景】报表明细数据导出，需要将大量数据导出，数据表总数据量 1000w, 单个查询导出 20~60w 数据。使用深度分页操作导致集群 BE 节点 CPU 几乎都打满，20/QPS。当前使用的 JDBC LIMIT ，每页 2000。同时还测试了 JDBC ResultSet 和 LIMIT 一样的容易将 CPU 打满，ResultSet 还容易将当前服务 JVM 内存打爆。

问题：

1. 在大数据量导出的情况下怎么使用才是最佳操作？
2. SR 的 ResultSet 是不是没有实现 Streaming read ？

【业务影响】集群不稳定，查询效率低
【StarRocks版本】2.4.4
【集群规模】例如：3fe（3 follower）+6be
【机器信息】16C/64G/万兆
【附件】

导出三种方式

不能通过分页的方式把数据导出，深度分页会把CPU打满了

除了分页有没有其他方式，在报表侧的导出不适合使用 Spark、Flink、或 Export，因为是在线的服务形式

另外 SR 的 ResultSet 是不是没有实现 Streaming read ？因为像 MySQL 虽然Limit深度分页有问题，但是通过 ResultSet 就可以

报表导出，可以整个结果导出，为什么一定要分页导出

整页导出用什么方式呢？如果全部拉回来单个查询就有几十万的数据，全部在内存中，服务的内存会撑爆。这就回到了咨询的另一个问题 ResultSet 的问题，发现 ResultSet 基于游标也会把所有数据拉回来放到内存

stream load是导入的，您说的ResultSet可以测试一下，我这边还没有具体的案例可提供，谢谢！

导出的话不要用order by limit 这种方式导出，可以考虑根据分区分桶导出

如果导出的数据的 WHERE 条件中没有包含分桶条件或者分桶的数据量也不小，其实效果也一样的是不

这个是不是对这类问题做的优化？

这个是客户端行为，客户端配一下 fetch_size 应该就可以了