Spring Boot中Ignite循环查询性能远逊于Postgres的问题排查

我正在对for循环中依次执行的多条SELECT语句做性能对比测试，应用从包含20000条随机生成数据的Ignite缓存中查询特定年龄的Person数据。计划针对18到98岁的每个年龄各执行1次SELECT，共81次查询。但测试发现Ignite性能远慢于Postgres：Postgres仅用5秒就能完成50次这类查询，而Ignite查询每个年龄组单次耗时超11秒。

实体与仓库定义 #

Person实体 #

@Entity
public class Person {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Integer id;
    private String name;
    @QuerySqlField(index=true)
    private Integer age;

    // Getters & Setters...
}

注：同时使用@Entity和@Id是为了通过Spring配置切换Ignite和Postgres数据源。

Ignite仓库接口 #

@RepositoryConfig(cacheName="Person")
@Repository
public interface IgnitePersonRepository extends IgniteRepository<Person, Integer> {
    @Query("SELECT * FROM Person WHERE age = ?")
    List<Person> findByAge(int age);
}

注：@Query注解来自Ignite而非JPA。

查询逻辑 #

public double findByAge(int lowerAge, int upperAge, int totalSelects) {
        List<Person> elements = new ArrayList<>();

        stopwatch.start();

        for (int i = lowerAge; i<upperAge; i++) {
            for (int noSelects = 0; noSelects < totalSelects; noSelects++) {
                elements.addAll(ignitePersonRepository.findByAge(i));
            }
        }

        return stopwatch.getElapsedTime();
    }

测试参数：lowerAge=18、upperAge=98、totalSelects=1。

疑问 #

已为Person的age字段显式添加索引，且写入测试中Ignite表现远优于Postgres，这种查询性能差异是正常的吗？问题出在哪里？

1. 检查Ignite缓存的部署与配置 #

• 部署模式：若Ignite采用分布式多节点部署，单次查询会产生节点间网络通信、数据定位的额外开销，而Postgres单节点无此问题。测试阶段先切换到本地模式，排除分布式损耗。
• 缓存类型：确认缓存是REPLICATED还是PARTITIONED。如果是PARTITIONED且未设置affinityKey，查询需要遍历所有分区，大幅增加耗时。对于20000条数据的场景，建议设置为REPLICATED，让每个节点持有全量数据，避免跨节点查询。

2. 优化查询方式，降低请求开销 #

Ignite的单条SQL查询存在初始化、连接建立的固定开销，你当前的循环是单次单请求，81次查询会累积大量重复开销，而Postgres在短连接复用、查询缓存上的优化更成熟。

优化方案：

• 批量查询：将多个年龄的查询合并为一次请求，用IN子句批量获取数据：

  @Query("SELECT * FROM Person WHERE age IN (:ages)")
  List<Person> findByAges(@Param("ages") List<Integer> ages);
  

  一次性传入18到98的所有年龄列表，将81次请求缩减为1次，大幅降低总耗时。
• 异步并行查询：若必须保留循环逻辑，改用IgniteAsyncRepository执行异步查询，并行处理多个请求，利用多线程提升效率。

3. 确认索引是否生效 #

虽然添加了@QuerySqlField(index=true)，但需验证索引是否正确创建并被使用：

• 查看Ignite启动日志，确认存在Creating SQL index for cache [cacheName=Person, indexName=PERSON_AGE]的日志条目，说明索引创建成功。
• 执行EXPLAIN SELECT * FROM Person WHERE age = 20查看执行计划，若输出包含INDEX SCAN则说明索引被使用，若为FULL SCAN则索引未生效，需检查实体配置或Ignite版本兼容性。

4. 减少序列化与传输开销 #

Ignite查询结果需要序列化后传输到客户端，低效的序列化或大结果集会拖慢性能：

• 确认Ignite使用BinaryMarshaller作为序列化器（默认配置），它比JDK序列化效率高数倍。
• 若无需返回全量字段，修改查询语句只获取必要字段，比如SELECT id, name FROM Person WHERE age = ?，减少序列化和传输的数据量。

5. 修正测试方法 #

• 添加预热步骤：Ignite首次查询会加载类元数据、初始化缓存，需在计时前先执行几次查询完成预热，避免将初始化时间计入测试结果。
• 隔离查询耗时：代码中elements.addAll(...)会占用CPU和内存，若结果集较大，这部分耗时会被误统计。测试时可暂时注释结果收集逻辑，只统计查询本身的耗时。

性能差异是否正常？ #

这种差异完全不正常。Ignite作为内存数据库，在单条简单索引查询上的性能应该远优于Postgres。出现当前情况基本是配置错误、查询方式不合理或测试方法有问题，按照上述步骤排查优化后，Ignite的查询性能应该能显著提升。

内容的提问来源于stack exchange，提问作者Mario Mateaș