测量SQL查询性能耗时是否需要遍历ResultSet的相关问题

核心结论 #

如果要统计SQL查询从客户端发起请求到获取全量结果的完整响应耗时，必须遍历整个ResultSet，仅统计executeQuery的执行时间是完全不准确的。 #

两种ResultSet认知的适用场景 #

你提到的两种认知分别对应不同的数据库驱动实现和配置：

• 全量加载模式：仅在你主动配置驱动参数（比如将fetchSize设置为Integer.MAX_VALUE，或者部分嵌入式内存数据库的默认策略）时生效，此时executeQuery会等待所有查询结果全部传输到客户端内存后才返回，这种场景下仅统计executeQuery耗时是准确的，但该模式会占用大量客户端内存，大结果集下容易OOM，极少作为默认配置使用。
• 流式/分批加载模式：这是绝大多数数据库驱动的默认行为，executeQuery仅完成以下动作：
  1. 向数据库发送SQL语句
  2. 接收数据库返回的执行状态确认、元数据信息和首批结果
     之后剩余的结果会在你调用rs.next()时，按照驱动配置的fetchSize分批从数据库拉取到客户端。你提到的DuckDB的向量化执行就是该模式的典型实现：DuckDB会按批次生成向量化的结果，只有遍历到对应批次时才会完成数据解码、转换为Java可读取的行格式，因此遍历的耗时占比会远高于executeQuery的耗时。

不同场景的正确测量方式 #

1. 仅需要统计数据库端纯执行耗时 #

直接使用数据库自带的执行分析工具即可，不需要通过Java代码统计：

比如DuckDB执行EXPLAIN ANALYZE 你的SQL语句，输出结果里的执行时间就是数据库端完成SQL解析、优化、执行的纯耗时，排除了网络传输、客户端拉取、数据解码的开销。

2. 需要统计业务视角的端到端完整耗时 #

测量起点放在executeQuery调用前，测量终点放在遍历完所有rs.next()之后，根据你的需求决定是否包含字段读取的开销：

• 如果需要统计「拿到所有可直接使用的业务数据」的总耗时，保留getXxx逻辑即可
• 如果仅需要统计「结果集完全传输到客户端」的耗时，只保留while(rs.next());空遍历即可
  对应的测试代码示例：

long startTime = System.currentTimeMillis();
Statement b = conn.createStatement();
ResultSet rs2 = b.executeQuery("Select o_orderkey, o_orderstatus, o_orderdate, o_orderpriority, o_comment from orders");
// 若仅统计结果拉取耗时，用空遍历即可：while(rs2.next());
while(rs2.next()){
    int okey=rs2.getInt(1);
    String st=rs2.getString(2);
    Date dt=rs2.getDate(3);
    String pr=rs2.getString(4);
    String co=rs2.getString(5);
}
long endTime = System.currentTimeMillis();
System.out.println(i+". DuckDB " + (endTime- startTime) +" ms");
// 测试完成后记得关闭资源避免干扰后续测试
rs2.close();
b.close();

测量时建议重复执行多次取平均值，排除数据库缓存、JVM JIT编译的干扰。 #

内容的提问来源于stack exchange，提问作者dave8s