Spring JDBC查询返回Optional结果的最优性能实现方案

问题背景 #

需要实现单值数据库查询返回Optional<String>类型结果，待执行SQL如下：

SELECT foo
FROM bar
WHERE baz = 123
LIMIT 1

该查询逻辑为：要么返回1行字符串类型的foo字段值，要么无匹配行。
已知Spring JDBC原生queryForObject方法在查询结果为空时会抛出EmptyResultDataAccessException，不满足空结果返回Optional.empty()的需求，候选实现基于query、queryForList、queryForStream三类API实现，需要对比各方案性能，同时确认是否存在惯用实现、非最优方案的权衡因素，以及foo字段允许为null时的歧义解决方案。

待对比的候选实现代码如下：

// 方案1
return jdbcTemplate.query(sql, (rs, i) -> rs.getString(0)).stream().findAny();

// 方案2
return jdbcTemplate.queryForList(sql, String.class).stream().findAny();

// 方案1.1/2.1 （qres为上述两个API返回的查询结果集合）
for (var res : qres) {
  return Optional.of(res);
}
return Optional.empty();

// 方案1.2/2.2
return qres.size() == 0 ? Optional.empty() : Optional.of(qres.get(0));

// 方案3
try(var stream = jdbcTemplate.queryForStream(sql, (rs, i) -> rs.getString(0))) {
  return stream.findAny();
}

方案性能对比结论 #

性能从优到劣排序：方案3 > 方案1/1.1/1.2 > 方案2/2.1/2.2
各方案性能差异的核心原因：

• 方案3（queryForStream实现）性能最优：该API不会将全量结果加载到内存集合，而是直接基于ResultSet做流处理，调用findAny()时只会读取第一行结果就立即关闭数据库资源，没有额外的集合初始化、元素拷贝开销，完全匹配LIMIT 1的查询语义。注意必须用try-with-resources包裹流，否则数据库连接、结果集资源会泄漏。
• 方案1系列（query+行映射器实现）性能次之：query方法传入RowMapper时，会逐行遍历ResultSet，把映射后的结果存入ArrayList后返回。因为SQL加了LIMIT 1，最终集合最多只有1个元素，内存开销极低，但相比流方案还是多了一层集合对象创建的成本。其中1.1（遍历取第一个元素）、1.2（直接取索引0元素）性能几乎无差异，比方案1里转stream再findAny少了流对象创建的开销，但差异在纳秒级别，实际业务中几乎感知不到。
• 方案2系列（queryForList实现）性能最差：queryForList传入元素类型String.class时，内部走的是SingleColumnRowMapper做映射，逻辑和方案1的行映射逻辑一致，但额外多了一层列类型校验、类型转换的分支判断开销，整体比方案1略慢，同样存在集合创建的成本。

场景惯用实现方式 #

除了上述手写方案，Spring JDBC从3.2版本开始就提供了原生支持：直接使用DataAccessUtils.singleResult()方法配合queryForList或者query使用，是官方推荐的惯用写法，示例：

// 原生惯用写法，空结果自动返回null，再包装为Optional
return Optional.ofNullable(
  DataAccessUtils.singleResult(jdbcTemplate.queryForList(sql, String.class))
);

如果项目中已经引入Spring Data JDBC，还可以直接用JdbcTemplate的扩展方法，直接返回Optional类型，不需要手动包装。

非最优方案的权衡考量 #

实际开发中不一定非要选性能最高的方案，通常需要权衡以下因素：

• 代码可读性：方案1.2、2.2的写法逻辑最直白，不需要理解流处理、资源关闭的注意点，新人接手代码时几乎没有理解成本，性能差异在绝大多数业务场景（QPS低于万级的查询）下完全可以忽略。
• 资源泄漏风险：方案3虽然性能最高，但要求开发者必须正确使用try-with-resources包裹流，一旦漏写会导致数据库连接泄漏，在代码审核不严格的团队里反而容易引发线上故障。
• 结果数量校验需求：如果后续业务逻辑调整，去掉了SQL里的LIMIT 1，DataAccessUtils.singleResult()方法会在结果数大于1时抛出异常，能及时发现数据不一致问题，而流的findAny()、直接取索引0的写法会静默取第一个元素，掩盖数据问题。

字段为null时的歧义解决方案 #

当foo字段允许为null时，Optional.empty()无法区分是「无匹配行」还是「匹配行字段值为null」，可以通过以下两种方案解决：

• 包装自定义结果对象：比如定义QueryResult<T>类，包含exists布尔标识和value字段，无匹配行时返回exists=false的实例，匹配行无论value是否为null都返回exists=true的实例。
• 使用嵌套Optional类型：比如用Optional<Optional<String>>做返回值，外层Optional.empty()代表无匹配行，外层Optional.of(Optional.empty())代表匹配行字段值为null，外层Optional.of(Optional.of(xxx))代表匹配行字段有值，但这种写法可读性较差，一般不推荐在业务代码中使用。

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