JDBC连接MySQL时批量执行大量无依赖SELECT查询的最快实现方案

完全可以在单次RTT内完成所有查询的执行与结果返回，且最优实现的整体延迟会比传统逐次发请求、甚至并发多连接发请求的模式低60%以上。

核心实现逻辑 #

整个流程的本质是消除无意义的网络往返开销：原本逐次发请求的模式，每发一条SQL就要等数据库返回结果才能发下一条，100条查询就会叠加100次RTT的延迟；把所有查询的请求报文打包后一次性发送、数据库端执行完所有查询后把结果打包一次性返回，就可以把网络交互次数压缩到1次。

注意：单RTT实现的前提是所有查询之间没有数据依赖，不需要等上一个查询的结果才能构造下一个查询的SQL，这点和你当前的场景完全匹配。
因为你描述的场景下单条查询返回结果仅数行，100条查询的结果总大小通常也就几KB到几十KB，打包后的报文完全不会触发带宽瓶颈，所有耗时基本集中在一次RTT的网络传输上，符合单RTT的要求。

从慢到快的可选实现方式 #

• 最基础的实现：数据库原生多语句接口
  绝大多数主流关系型数据库都支持开启单次请求内发送多语句的能力，只需要在数据库连接的初始化参数里打开对应开关（比如MySQL需要开启multiStatements参数），把100条SQL用数据库约定的分隔符拼接成单个字符串，一次性发送给数据库即可。
  数据库端会按顺序执行完全部SQL后，将对应的所有结果集按提交顺序依次序列化、一次性打包返回，客户端接收后按顺序拆分各个ResultSet就能拿到所有查询结果。
  这个模式的额外开销主要来自100次SQL的解析、权限校验过程，整体执行时间通常是百微秒到毫秒级，完全可以被单次RTT的时长覆盖。
• 最快的实现：单查询结构化聚合打包
  相比单纯用分号拼接裸多语句，这个模式的延迟更低，核心是把100条无依赖的查询合并成单条数据库只需要解析1次的结构化查询，从根源上省掉重复解析的开销：
  • 如果查询是同表带不同过滤条件的场景，直接用IN、VALUES临时表关联的方式，把所有过滤条件合并到单条查询里，一次就能拉回所有匹配的行
  • 如果查询涉及不同表的场景，用UNION ALL把所有SELECT语句拼接成单条查询，给每个原始查询加固定的标记字段做结果区分，甚至可以直接用数据库原生的JSON聚合函数，把每条查询的结果聚合成独立的JSON对象，最后返回一个包含所有结果的单JSON值
    这种模式下，数据库端只需要做1次SQL解析、1次权限校验，返回的报文是单个结构化的JSON/单行结果，不管是数据库端的序列化开销还是客户端的解析开销，都比多语句多结果集的模式低30%以上，是当前场景下能最快拿到全量结果的路径。

需要避开的常见误区 #

• 不要用带等待逻辑的批量中间层：很多ORM框架的批量操作是为了攒够一定数量的请求才统一发送，会引入几十到上百ms的额外等待延迟，反而比直接一次性发送全量请求慢
• 不要用开100个并发连接逐次发请求的方案：这个模式会引入100次TCP握手、TLS认证的开销，公网环境下还可能触发运营商的连接数限流，整体延迟远高于单通道打包发送
• 要关闭数据库连接的逐行返回模式：比如MySQL默认的逐行fetch模式会导致结果集逐行回传，相当于变相增加网络往返次数，需要开启全量结果集一次性返回的配置，确保所有计算完成后一次性把结果打包回传。

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