Spring Boot JPA插入FeatureEntity如何优化多次findBy查询

CriteriaBuilder完全适用于你的场景，相比当前三次独立findBy的实现，它可以通过单次关联查询完成全部三项前置校验，把数据库交互次数从3次降到1次，既减少了网络IO开销，也规避了多次查询之间的数据一致性窗口问题，执行效率和可靠性都更高。
如果你的校验规则没有动态拼接的需求，也可以选择更轻量的Spring Data JPA派生查询、JPQL方案，实现成本更低，性能和CriteriaBuilder完全一致。

• 三次独立数据库请求，每次都要经历连接获取、SQL执行、结果返回、连接释放的流程，高并发场景下性能损耗非常明显
• 校验逻辑非原子：第一次查询到应用为激活状态后，到查询版本的时间间隙里如果应用被修改为未激活状态，会出现校验通过但实际数据不合法的问题
• 参数传递冗余：查询版本时需要提前拿到应用ID、属性名作为入参，逻辑链路长，容易出现传参错误（比如你贴的代码里就存在applicatonRepo、attibute这类拼写错误）

首先调整你的Repository接口，继承JpaSpecificationExecutor以支持Criteria API查询：

import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.JpaSpecificationExecutor;

public interface ApplicationVersionRepository extends JpaRepository<ApplicationVersionEntity, Integer>, JpaSpecificationExecutor<ApplicationVersionEntity> {
}

业务层实现逻辑，单次查询完成全部校验：

import jakarta.persistence.criteria.Join;
import org.springframework.data.jpa.domain.Specification;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class FeatureBizService {

    private final ApplicationVersionRepository appVersionRepository;
    private final FeatureRepository featureRepository;

    // 构造函数注入 不需要@Autowired
    public FeatureBizService(ApplicationVersionRepository appVersionRepository, FeatureRepository featureRepository) {
        this.appVersionRepository = appVersionRepository;
        this.featureRepository = featureRepository;
    }

    @Transactional(rollbackFor = Exception.class)
    public void createValidFeature(String appCode, int major, int minor, String attributeName, String featureName) {
        Specification<ApplicationVersionEntity> validSpec = (root, query, cb) -> {
            // 关联应用表 校验应用状态和编码
            Join<ApplicationVersionEntity, ApplicationEntity> appJoin = root.join("applicationEntity");
            // 关联属性表 校验属性匹配
            Join<ApplicationVersionEntity, AttributeEntity> attrJoin = root.join("attributeEntity");

            // 所有校验条件合并到同一个where子句
            return cb.and(
                    cb.equal(appJoin.get("code"), appCode),
                    cb.isTrue(appJoin.get("isActive")),
                    cb.equal(root.get("major"), major),
                    cb.equal(root.get("minor"), minor),
                    cb.equal(attrJoin.get("name"), attributeName)
            );
        };

        // 单次查询 结果为空就代表任意一项校验不通过
        ApplicationVersionEntity validVersion = appVersionRepository.findOne(validSpec).orElse(null);
        if (validVersion == null) {
            throw new IllegalArgumentException("校验失败：应用未激活/指定版本不存在/版本未绑定目标属性");
        }

        // 校验通过 组装实体保存
        FeatureEntity feature = new FeatureEntity();
        feature.setName(featureName);
        feature.setApplicationEntity(validVersion.getApplicationEntity());
        feature.setApplicationVersionEntity(validVersion);
        feature.setToBeImplemented(false);
        featureRepository.save(feature);
    }
}

注意：@ManyToOne关联默认是即时加载（FetchType.EAGER），查询到ApplicationVersionEntity时，关联的ApplicationEntity和AttributeEntity会被一并查出，不需要额外发起查询。

如果你的校验条件是固定的，不需要根据入参动态增减规则，完全不用写CriteriaBuilder，直接在Repository里定义派生查询即可，代码量更少，性能一致：

// 直接通过方法名派生关联查询 单次执行完成所有校验
Optional<ApplicationVersionEntity> findByMajorAndMinorAndApplicationEntity_CodeAndApplicationEntity_IsActiveTrueAndAttributeEntity_Name(
        int major,
        int minor,
        String appCode,
        String attributeName
);

业务层直接调用这个方法即可，不需要额外写Specification构造逻辑。

• 给application_version表建联合索引：(major, minor, application_id, attribute_id)，可以把查询耗时降到毫秒级
• 如果其他场景查询ApplicationVersionEntity不需要每次都加载关联的应用、属性，可以把@ManyToOne的加载策略改为FetchType.LAZY，在这个校验场景的Criteria查询里用fetchJoin替代普通join手动加载需要的关联对象，避免不必要的字段查询。

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