Java ORM 代码量和性能对比:DoytoQuery vs SpringDataJPA/SpringJdbc/jOOQ/MyBatis-plus

TL;DR

代码量: DoytoQuery << SpringDataJPA/MyBatis-plus < jOOQ << SpringJdbc

查询性能:SpringJdbc > DoytoQuery > jOOQ >>> SpringDataJPA > MyBatis-plus

测试代码:github.com/f0rb/java-o...

介绍

本文基于几个常用的动态查询场景对比了基于对象查询映射(Object Query Mapping, OQM)方法的框架DoytoQuery与常用ORM框架(Spring Data JPA、Spring JDBC、jOOQ、MyBatis-plus)的代码量和查询性能。

实验设计

本实验旨在评估 DoytoQuery 与其他主流ORM框架在处理典型动态查询任务时的开发成本和运行效率。

实验对象

数据集来自Kaggle提供的工资数据 Data Science Salaries,共计 136,757 条记录。每条记录包含工作岗位、薪资、经验、工作类型、公司规模、工作地点等字段,适合构造多种复杂的动态查询场景。

对比框架

框架 简介
DoytoQuery OQM框架,通过声明式查询模型自动构建SQL语句
Spring Data JPA Hibernate 封装的高层 ORM 框架
Spring JDBC 基于 JDBC Template 的底层访问方式
jOOQ 提供类型安全 SQL 构造的 DSL 框架
MyBatis-plus MyBatis 增强工具,自动封装 CRUD

查询场景

为了覆盖不同类型的查询逻辑,设计了以下三个查询任务:

编号 描述
T1 查询 2025 年薪资在 20,000 和 100,000 之间的记录
URL /salary/?workYear=2025&salaryInUsdGt=20000&salaryInUsdLt=100000&pageSize=10
SQL SELECT * FROM salary WHERE work_year = ? AND salary_in_usd < ? AND salary_in_usd > ? LIMIT 10 OFFSET 0
T2 查询岗位为 "Researcher",薪资小于 30,000 或大于 300,000 的记录
URL /salary/?jobTitle=Researcher&or.salaryInUsdLt=30000&or.salaryInUsdGt=300000&pageSize=10
SQL SELECT * FROM salary WHERE job_title = ? AND (salary_in_usd < ? OR salary_in_usd > ?)
T3 查询 2025 年薪资高于 2023 年最大薪资的记录
URL /salary/?workYear=2025&salaryInUsdGt0.workYear=2023
SQL SELECT * FROM salary WHERE work_year = ? AND salary_in_usd > (SELECT max(salary_in_usd) FROM salary WHERE work_year = ?)

查询对象统一建模

为了保证对比公平,所有框架均通过统一的查询对象 SalaryQuery 实现参数处理:

java 复制代码
public class SalaryQuery extends PageQuery {
    private Integer workYear;
    private String jobTitle;
    private Double salaryInUsdLt;
    private Double salaryInUsdGt;
    private SalaryQuery or;
    private SalaryQuery salaryInUsdGt0;
}

评估指标

  • 代码量(Code Size):统计方法代码行数与总体代码行数(LOC),评估代码维护成本。
  • 性能(Performance):使用JMH测量每秒处理请求数量(ops/s),评估执行效率。

实验环境

  • 硬件

    • CPU: Intel Core i5-13600KF
    • 内存: 16GB DDR5
    • 存储: 1TB SSD
    • GPU: NVIDIA RTX 2060 Super
  • 软件

    • 操作系统: Windows 11 Pro
    • 数据库: MySQL 8.3.0
    • JDK: Amazon Corretto 17.0.5
    • Benchmark 工具: JMH 1.37
    • 框架版本:Spring Boot 3.5.0、Spring Web 6.2.7 等
  • Benchmark 配置

java 复制代码
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
@State(Scope.Benchmark)
@Fork(value = 2, jvmArgs = {"-Xms256M", "-Xmx2G", "-XX:+UseG1GC"})
@Threads(8)
@Warmup(iterations = 8, time = 1)
@Measurement(iterations = 3, time = 3)
public class ORMBenchmark { /*...*/ }

实验结果

DQ: DoytoQuery JDBC: Spring JDBC JPA: Spring Data JPA MP: MyBatis-Plus

代码量对比

分析

  • DoytoQuery 基于声明式查询模型,无需编写动态查询构建方法,总代码量远低于其他框架。
  • ORM框架都需要通过指令式编程构建SQL语句,构建动态查询的代码量相近。

这里仅对比了查询代码。如果需要实现完整的增删查改接口,Spring JDBC 需要自行拼接SQL语句,代码量最高;Spring Data JPA,jOOQ,MyBatis-Plus都封装了基本的增删查改语句构建,代码量次之;DoytoQuery实现了SQL语句的完全自动化构建,代码量最少。

总体来看,DoytoQuery在代码复用与简洁性上优于传统ORM框架

性能对比

分析

  • Spring JDBC由于采用字符串拼接SQL,性能最佳。
  • DoytoQuery与jOOQ性能其次。
  • Spring Data JPA 和MyBatis-Plus的表现最弱。

总结

实验表明,OQM方法通过声明式查询模型自动构建SQL语句,在代码量上远低于ORM框架。同时,其运行性能接近Spring JDBC,并优于其他ORM框架,验证了OQM方法在实际应用中的可行性与优势。

相关推荐
努力的小雨6 小时前
还在为调试提示词头疼?一个案例教你轻松上手!
后端
魔都吴所谓6 小时前
【go】语言的匿名变量如何定义与使用
开发语言·后端·golang
陈佬昔没带相机7 小时前
围观前后端对接的 TypeScript 最佳实践,我们缺什么?
前端·后端·api
Livingbody8 小时前
大模型微调数据集加载和分析
后端
Livingbody9 小时前
第一次免费使用A800显卡80GB显存微调Ernie大模型
后端
Goboy9 小时前
Java 使用 FileOutputStream 写 Excel 文件不落盘?
后端·面试·架构
Goboy9 小时前
讲了八百遍,你还是没有理解CAS
后端·面试·架构
麦兜*10 小时前
大模型时代,Transformer 架构中的核心注意力机制算法详解与优化实践
jvm·后端·深度学习·算法·spring·spring cloud·transformer
树獭叔叔10 小时前
Python 多进程与多线程:深入理解与实践指南
后端·python
阿华的代码王国10 小时前
【Android】PopupWindow实现长按菜单
android·xml·java·前端·后端