为何循环调用findById(...)比findAllById(...)更快？（JPA、Hibernate等）

以下是几种可能的原因：

• 查询执行逻辑差异
  逐个调用findById会发起10次独立的单条查询（SELECT * FROM table WHERE id = ?），而findAllById一般会生成带IN条件的查询（SELECT * FROM table WHERE id IN (?, ?, ...)）。如果你的数据库对IN查询的优化不到位——比如没有高效利用主键索引，或者处理IN列表时生成的查询计划不够优，那多次单条查询的总耗时反而会更低。哪怕只有10个ID，不同数据库的优化策略也可能导致这种差异。

• ORM结果映射的开销
  findAllById需要一次性把所有查询结果映射成实体对象，如果你的实体关联了其他表、字段较多或者对象本身比较“重”，ORM框架一次性处理大量结果的开销会比分批处理单条结果更大。而逐个调用时，每次只处理一个实体，内存占用和处理压力都更小，速度自然更快。

• 缓存的影响
  如果ORM框架的一级缓存（比如Hibernate的Session缓存）里已经有这些实体的缓存，那逐个调用findById会直接从缓存取数据，根本不用走数据库。而findAllById可能会直接触发数据库查询，或者缓存命中的逻辑不一样，没用到已有的缓存，导致速度变慢。

• 网络与连接池的实际表现
  别觉得多次查询网络开销就一定大——如果数据库连接池配置合理，连接复用效率高，单条查询的响应又极快，10次单条查询的总网络开销可能比一次IN查询还小。比如IN查询返回的结果集更大，传输时间更长，或者数据库内部处理IN查询的逻辑更复杂（比如排序、去重），反而拖慢了整体速度。

代码示例 #

val listIds = List.of(1,2,3,4,5,6,7,8,9,10);

// 更快的实现
val entityList = listIds
            .stream()
            .map(id -> repository.findById(id).orElseThrow())
            .collect(Collectors.toList());


// 更慢的实现
val entityList = repository.findAllById(listIds);

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