Easy Query 不是又一個“幫你少寫 SQL”的小工具，它更像是把 Java 里的復雜查詢、對象關系、分庫分表、讀寫分離都往一套強類型表達式里收。

Java 后端寫數據庫，很多人嘴上說習慣了，手上其實早就煩了。

MyBatis 靈活，但 XML 和手寫 SQL 寫多了，改字段名時心里會咯噔一下。JPA 很對象化，但復雜查詢、動態條件、性能控制一上來，又容易讓人想退回 SQL。

于是項目里經常出現一種混搭：簡單查詢用 ORM，復雜查詢手寫 SQL，報表查詢另開一套，分頁、邏輯刪除、多租戶、分表再補插件。

能跑。也能累。

Easy Query 狠的地方，不是喊“替代 MyBatis/JPA”，而是它敢把復雜 SQL 寫成強類型 Java 表達式：字段能點出來，關系能走出來，join 和子查詢不再全靠字符串硬拼。

最先刺到人的，是強類型查詢

手寫 SQL 最怕什么？不是長，是脆。

字段名改了，XML 里不會哭；表結構動了，字符串不會提醒你；IDE 也很難像檢查 Java 代碼一樣檢查 SQL 片段。

Easy Query 的一個主線，就是把查詢表達式拉回 Java 類型系統里。README 里提到它擁有強類型表達式，并提供代理模式支持 APT 生成代理對象。

@Table("t_blog")
@EntityProxy
public class BlogEntity extends BaseEntity
implements ProxyEntityAvailable {
// fields...
}

有了代理對象后，查詢不再只是字符串拼裝，而是可以寫成鏈式表達式。

Topic topic = easyEntityQuery
.queryable(Topic.class)
.where(o -> o.id.eq("3"))
.firstOr;

這類寫法的爽點很直接：能點出來的字段，就比手寫字符串更讓人安心。尤其是后臺項目跑幾年以后，字段重命名、表拆分、DTO 調整，都是遲早的事。

五大隱式，才是它最炸的地方

官方 README 開頭就把“五大隱式”擺出來了：隱式 join、隱式子查詢、隱式分組、隱式分區分組、隱式 CASE WHEN 表達式。

這幾個詞看著有點猛，落到代碼里其實很好懂：你按對象關系寫，它幫你把背后的 SQL 關系翻出來。

能力 適合干什么

隱式 join

按關聯對象字段篩選、排序、取結果

隱式子查詢

按一對多、多對多關系做 any、max 等條件

隱式分組

把多個子查詢合并成分組查詢

隱式分區分組

取關聯集合里第一個、第 N 個數據參與篩選

隱式 CASE WHEN

聚合函數加篩選條件

比如查詢“用戶所屬企業是 xx 公司”，代碼不是先手寫 join，再管表別名，再補排序，而是直接沿著關系寫：

List userInXXCompany = entityQuery.queryable(SysUser.class)
.where(user -> {
user.company.name.like("xx公司");
})
.orderBy(user -> {
user.company.registerMoney.desc;
user.birthday.asc;
}).toList;

這段最有意思的地方，是 user.company.name 。你寫的是對象關系，最后走的是數據庫查詢。ORM 如果只是省幾行 CRUD，沒什么稀奇；能把關系查詢寫順，才真有味道。

一對多查詢，不用每次都手寫 exists

后臺系統里，一對多條件太常見了。

查“有小明這個員工的公司”，查“有未付款訂單的用戶”，查“最近一次登錄異常的賬號”。這種需求寫 SQL 不難，但每次都要把 exists、子查詢、聚合塞進去，代碼很快變厚。

Easy Query README 里的隱式子查詢例子是這樣的：

List companies = entityQuery.queryable(Company.class)
.where(company -> {
company.users.any(u -> u.name.like("小明"));
company.users
.where(u -> u.name.like("小明"))
.max(u -> u.birthday)
.gt(LocalDateTime.of(2000, 1, 1, 0, 0, 0));
}).toList;

這就不是“少寫一個 mapper 方法”了。

它是在把復雜查詢的表達力往 Java 對象關系上挪。你還得懂 SQL，但不用把每個關系都拆成字符串來手工拼。

Easy Query 不會讓你不用懂 SQL。恰恰相反，越是復雜查詢，越需要你知道背后會生成什么 SQL。它解決的是另一件事：別把 SQL 的脆弱字符串散得到處都是。

不止查詢，后臺那些老賬它也管

如果 Easy Query 只會 queryable，那它頂多算一個強類型查詢器。

但 README 里列的范圍要大得多：單表查詢、多表查詢、union、子查詢、分頁、動態表名、VO 對象查詢返回、邏輯刪除、全局攔截、數據庫列加密、數據追蹤差異更新、樂觀鎖、多租戶、自動分庫、自動分表、讀寫分離。

這份清單看完，你就知道它不是給 demo 用的。

后臺常見麻煩 Easy Query 文檔/README 提到的能力

軟刪除

@LogicDelete

邏輯刪除

復雜查詢

join、union、子查詢、聚合、分頁

大表拆分

自動分庫、自動分表

多租戶系統

多租戶、全局攔截

讀多寫少

讀寫分離

這里要說句實話：能力多，也意味著你不能隨手就往老項目里懟。

ORM 是數據庫訪問的主干，不是工具類。你要先拿一個模塊驗證查詢風格、生成 SQL、事務邊界、分頁結果和線上排查方式。

國產數據庫和分析庫也沒落下

README 的數據庫支持表里，列了 MySQL、Oracle、PostgreSQL、SqlServer、H2、SQLite、ClickHouse、達夢、人大金倉 KingbaseES、高斯、DuckDB、DB2 等。

這點對現在的企業項目挺現實。

以前只盯 MySQL 還行，現在一進政企、金融、數據平臺，國產數據庫、分析庫、信創環境一上來，ORM 的數據庫適配就不是加分項，而是門檻。

Spring Boot 接入，看起來不繞

README 里給的 Spring Boot 依賴很直接：

com.easy-query
sql-springboot-starter
${easy-query.version}

項目 POM 當前顯示的版本是 3.2.10 ，Gitee releases 頁面能看到 3.1.48 發布記錄。實際接入時，以 Maven Central、項目倉庫和官方文檔里的最新版本為準。

另外，強類型代理相關能力需要實體對象添加 @EntityProxy ，再通過 APT 生成代理對象。這個步驟要讓團隊熟悉，不然新人第一次看到 BlogEntityProxy 會愣一下。

別急著喊替代，先看你是哪種項目

如果你現在的系統就是幾十張表、CRUD 很直、團隊 MyBatis 用得順，Easy Query 不一定非上不可。

但如果你已經開始遇到這些情況，我會認真試一把：

復雜篩選越寫越長；join 和子查詢散在一堆 XML 里；字段重構很怕漏；多租戶、邏輯刪除、讀寫分離要統一收口；還要兼顧分庫分表或國產數據庫。

這時 Easy Query 的強類型表達式和對象關系查詢，就不是花活了。