有人問“hibernate還有人用嗎”這個問題我?guī)缀趺磕甓紩诩夹g群里看到一次。我的回答一直很直接只要你的Spring Boot項目還在用Spring Data JPA那底層跑的就是Hibernate。所謂“Hibernate過氣”無非是大家不用再天天面對SessionFactory和HQL的細節(jié)了框架本身反而活得好好的。也正因如此很多開發(fā)者在寫JPA的時候遇到一個看似簡單的問題反而卡住了Hibernate里的別名Alias到底是什么這個問題的答案其實貫穿了HQL、JPQL、Criteria查詢和原生SQL映射的方方面面。如果你總是不清楚select u.name from User u里的這個u是干嘛的或者原生SQL把列映射回實體的規(guī)則是什么那么這篇內容就是沖著你來的。我會從別名要解決什么問題講起再分場景拆解HQL、Criteria、原生SQL里別名的用法和坑最后給一個可以直接收藏的踩坑速查表。1. 別名到底解決什么問題一張關系表上的三個角色1.1 一句話說清別名就是一個引用標簽先說最樸素的定義。在SQL里別名就是給表或列起的一個臨時名字作用是在一條語句里指代這個對象省得每次都寫完整的表名和列名。select u.name from t_user u這里的u就是t_user這張表的別名。到了Hibernate這里含義又擴展了一點。HQL里from User uu是實體別名原生SQL里select u.id as user_iduser_id是列別名Criteria里root.join(pet, JoinType.LEFT)的返回值本質上也是Hibernate幫你管理的路徑引用。這三個東西都叫別名但作用位置不同混在一起想就亂了。我用一個生活類比幫新手理解別名相當于微信里的備注名。你不必每次都說“那個頭像很酷、上個月一起吃過飯、做后端開發(fā)的朋友”只需要說“老張”對方就知道是誰。在關系數(shù)據(jù)庫的查詢里也一樣一張表一旦出現(xiàn)在多條子句里你不能每次都重復全名得給它一個“老張”式的稱呼這就是別名。1.2 三種別名別搞混實體別名、列別名、路徑別名把三種別名放在一起對比一次后面就不會混淆了。實體別名作用于HQL/JPQL代表的是持久化實體對象本身列別名作用于SQL結果集代表查詢出的某個字段也是原生SQL映射回實體屬性的關鍵路徑別名則是Criteria查詢里對關聯(lián)對象引用的一種封裝。有個印象特別深的例子。同事在排一個查詢問題看到日志里Hibernate生成的SQL是select u1_0.id, p1_0.name from t_user u1_0 left join t_pet p1_0 on u1_0.idp1_0.user_id他問我“這個u1_0是什么我沒寫過這個別名”。這就是Hibernate在把HQL解析成SQL時自動生成的實體別名規(guī)則是實體首字母加數(shù)字序號用來保證一條復雜SQL里同名實體不打架。這個概念理解清楚了以后看Hibernate打印的SQL日志就不會覺得是一堆亂碼了。2. HQL中的別名查詢邏輯的骨架2.1 from子句的實體別名與where引用HQL寫出來的第一步就是決定給核心實體一個什么別名。from User u是整個查詢的主語后續(xù)所有對User字段的限制都通過u.xxx來寫。比如要查年齡大于18的用戶就寫where u.age 18按名字排序就寫order by u.name。這里有一個常見誤區(qū)很多人以為HQL里的別名是給數(shù)據(jù)庫表用的所以誤寫成了from t_user u。HQL的對象不是表而是實體所以必須是from User u這里的User是Java類名。如果你用原生的t_user寫HQLHibernate直接拋org.hibernate.hql.internal.ast.QuerySyntaxException。實體的別名隨意起但建議短且有辨識度u、p、o這類就夠用不需要起一長串。還有一點值得注意HQL里別名可以不出現(xiàn)在select里只出現(xiàn)在where里。from User u where u.age 20select其實是整行實體這里別名u只負責限定條件。這時候如果打印SQL日志你會看到Hibernate生成的SQL里select了所有字段這是正常的因為Hibernate需要把整個實體組裝出來。2.2 隱式路徑表達式Hibernate幫你起名有時候你不需要顯式聲明別名也能寫出帶關聯(lián)字段的HQL。比如查所有有寵物的用戶from User u where u.pet is not null。這里的u.pet是路徑表達式Hibernate會在內部創(chuàng)建一個關于pet關聯(lián)的隱式別名并自動生成一個inner join的SQL。這種寫法省事但有兩個風險。一是在一個較長的HQL里如果多次通過路徑表達式訪問同一個關聯(lián)的屬性Hibernate內部可能會生成多個隱式join雖然語義上等價但生成的SQL可能會有重復join的情況性能和可讀性都受影響。二是在select子句里想同時返回User和Pet卻不顯式聲明別名寫法會變得非常繞。所以我在實際項目里有一條約定只要一條HQL里出現(xiàn)了兩個或以上的實體就明確給每個實體起別名并且把join關系寫清楚不要依賴隱式路徑。比如from User u left join u.pets p where p.name like %球%。這樣代碼的可讀性、可維護性都強得多排查問題時也能一眼看出是哪張表和哪張表在join。2.3 select子句投影和聚合上下文別名在select子句里還有一個重要任務承載投影結果。select u.name from User u返回的是字符串列表select u from User u返回的是User實體列表。別名放的位置不同結果類型完全不同。更常見的是DTO投影寫法這是Hibernate用戶必須掌握的select new com.example.UserDTO(u.id, u.name, u.age) from User u where u.age 18這里UserDTO是一個普通Java類必須有對應的構造函數(shù)。Hibernate會按位置把別名列出的字段值填入構造函數(shù)。這就是我們通常說的“select new”動態(tài)實例化。它比返回Object[]再手動轉DTO要優(yōu)雅得多。聚合場景下別名的角色更微妙。select u.age, count(u) from User u group by u.age having count(u) 5這里count(u)中的u不是值本身而是代表“整行實體的數(shù)量”。初學者容易把u當成某個字段來理解其實它指向的是查詢的主體實體。還有一個官方文檔里明確寫的規(guī)則select子句出現(xiàn)的別名、屬性表達式必須在group by或聚合函數(shù)中保持一致否則數(shù)據(jù)庫報錯只是時間問題。比如按u.age分組同時select了u.name大多數(shù)關系型數(shù)據(jù)庫會直接拒絕執(zhí)行。3. Criteria和API層里的Alias連接與命名的藝術3.1 用createAlias關聯(lián)查詢路徑Hibernate的舊版Criteria API里有一個專門為別名設計的方法createAlias(String associationPath, String alias)。很多老項目里的代碼是這樣寫的Criteria criteria session.createCriteria(User.class); criteria.createAlias(pets, p); criteria.add(Restrictions.eq(p.name, 旺財)); ListUser users criteria.list();這里pets是User實體里的關聯(lián)屬性名p是賦給這個關聯(lián)路徑的別名。創(chuàng)建后后續(xù)所有關于Pet的條件都通過p.xxx來寫不再需要寫pets.name這種長路徑。這樣寫的好處是一方面省字另一方面當你需要多次操作同一個關聯(lián)對象時別名能保證Hibernate只生成一個join。有人會問能不能直接寫criteria.add(Restrictions.eq(pets.name, 旺財))能功能上沒問題但一旦你需要在同一個條件里多次引用pets或者要限制join的類型left join、inner join沒有別名就非常痛苦。更麻煩的是老版Criteria里如果多次用字符串路徑pets.nameHibernate內部會為同一個屬性路徑生成多個不同的隱式別名最后查出來的結果可能正確但生成的SQL又臭又長。3.2 Root.join與fetch join的別名到了JPA的CriteriaBuilder時代老朋友createAlias變成了Root.join。例如CriteriaBuilder cb entityManager.getCriteriaBuilder(); CriteriaQueryUser query cb.createQuery(User.class); RootUser root query.from(User.class); JoinUser, Pet petJoin root.join(pets, JoinType.LEFT); query.where(cb.equal(petJoin.get(name), 旺財));這里的petJoin就是路徑的持柄它和Hibernate老API里的字符串別名不太一樣它是類型安全的對象別名所有后續(xù)條件都通過petJoin.get(...)來寫。好處是編譯期能檢查路徑是否存在缺點是沒有老版那么直觀。真正的坑在fetch join上。root.fetch(pets, JoinType.LEFT)返回的是Fetch而不是Join但它也會在底層創(chuàng)建別名。如果你同時想對pets加條件還另外寫了一個root.join(pets)Hibernate不會自動幫你把fetch的join和條件的join合并最后可能生成兩個獨立的join結果出現(xiàn)重復記錄。我的處理習慣是需要過濾關聯(lián)對象時只做join不加fetch只是為了避免N1查詢時只用fetch不join。兩條路盡量分開走別交叉。3.3 老坑路徑字符串和別名覆蓋這里說一個非常有代表性的老坑。舊版Criteria里createAlias(pets, p)之后再調用createAlias(pets.tags, t)第一次的p別名依然有效。但如果兩次分別創(chuàng)建了指向同一路徑的不同別名比如createAlias(pets, p)和createAlias(pets, pet)Hibernate會產生兩個獨立的join條件分別加到各自的別名上。這個行為看著沒毛病卻會導致結果集會比預期多出很多行。排查時看到SQL日志里出現(xiàn)兩次對t_pet表的join第一反應就應該是某處重復創(chuàng)建了別名。另外字符串路徑不存在時會拋org.hibernate.QueryException: could not resolve property: pets2 of: com.example.User。這類報錯信息其實已經(jīng)把問題點說得很清楚了但網(wǎng)絡上的中文回答有時會繞到別名機制本身。我建議排查時直接把HQL或Criteria路徑拆開逐級驗證先確認User里有pets再確認Pet里有name基本十分鐘內能定位。4. 原生SQL查詢列別名是結果映射的唯一橋梁4.1 傳統(tǒng)createSQLQuery映射到實體當查詢需求用HQL或Criteria不好表達時我們會選擇寫原生SQL。原生SQL返回的是扁平的列Hibernate要靠“列名與屬性名的對應關系”把行數(shù)據(jù)組裝成實體。這個對應關系就是列別名。舊版Hibernate的經(jīng)典寫法是這樣的Query query session.createSQLQuery( select u.id, u.name, u.age from t_user u where u.age 18) .addEntity(User.class); ListUser users query.list();這里u.id這一列Hibernate在沒有任何列別名提示的情況下會拿列名id去匹配User實體標注的Column(name id)。一旦表字段和實體屬性命名不一致比如數(shù)據(jù)庫列叫user_name實體屬性叫name就必須在SQL里顯式起別名select u.user_name as name, u.age as age from t_user uas后面的別名name必須和實體User的屬性名完全一致。這就是為什么很多老項目的原生SQL看起來特別啰嗦滿眼都是as xxx——那不是作者有強迫癥是被映射規(guī)則逼的。4.2 Spring Data JPA的nativeQuery與DTO投影現(xiàn)代項目用Spring Data JPA寫原生SQL更常見。原生查詢加DTO接口投影的組合值得單獨說。例如public interface UserNameView { String getName(); Integer getAge(); } Query(value select u.user_name as name, u.age as age from t_user u, nativeQuery true) ListUserNameView findAllNames();這里的as name和as age就是Spring Data的代理對象用來生成接口方法返回值的依據(jù)。如果列別名和接口方法名對不上Spring會拋出轉換異常說“無法找到名為name的屬性”甚至直接返回null但不報錯。我建議寫這種查詢的時候在注解下方保留一條SQL注釋標明每個別名對應接口的哪個方法方便后來人維護。HQL版本里做DTO投影用的是select new原生SQL用的是別名匹配兩種方式背后的理念完全不一樣HQL是面向對象模型SQL是面向列結構。理解了這點你就不會在原生SQL里寫select new com.example.DTO(...)了因為那個語法只在HQL里有效。4.3 標量查詢讓無名列變成有名字的列原生SQL里還有一種情況查詢兩個字段做統(tǒng)計比如select count(*) from t_user。這個列本身沒有名字Hibernate返回的Object[]里只有一個元素類型是BigInteger或Long看日志時根本不知道對應什么。所以標量查詢時給列起別名也有現(xiàn)實意義Query query session.createSQLQuery( select u.age as age, count(*) as cnt from t_user u group by u.age); ListObject[] rows query.list(); for (Object[] row : rows) { Integer age (Integer) row[0]; Long cnt (Long) row[1]; }對象數(shù)組里的下標順序對應select子句里的列順序這個不依賴別名。但如果你用了setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP)列別名age和cnt就會變成Map的key取數(shù)據(jù)時直接map.get(cnt)可讀性就上來了。新版Hibernate里推薦用原生查詢加NativeQuery接口配合ResultTransformer思路是一樣的只是API換了殼。5. 別名踩坑速查表與排查思路5.1 別名問題速查表這些年處理過的Hibernate別名相關問題我整理成了一張速查表。碰到類似報錯先對著查一下通常能省下半個小時試錯?，F(xiàn)象報錯/表現(xiàn)原因處理方式HQL里寫了表名QuerySyntaxException: t_user is not mapped把表名當實體名用了改成實體類名User原生SQL查詢返回null字段字段為null但不報錯列名與實體屬性名不匹配在SQL里加as 實體屬性名Criteria關聯(lián)路徑報錯could not resolve property: xxx關聯(lián)屬性名拼寫錯誤或不存在檢查實體類字段名逐級驗證查詢結果出現(xiàn)大量重復行結果集行數(shù)遠超預期同一路徑重復創(chuàng)建別名導致多次join只創(chuàng)建一個別名并復用同一個引用DTO投影字段全null接口方法返回null列別名和DTO接口方法名不一致保持as別名與接口方法名一致聚合查詢報錯數(shù)據(jù)庫提示“列必須出現(xiàn)在GROUP BY中”select的字段沒有包含在group by檢查select與group by字段清單這張表雖然簡單但項目里真正出問題的場景絕大多數(shù)都能歸到這幾類中。5.2 一個實用的排查技巧最后分享一個排查技巧遇到任何疑似別名導致的查詢問題第一件事不是看代碼而是打開Hibernate的SQL日志輸出。把hibernate.show_sqltrue打開找到那條被執(zhí)行的SQL對照一下where條件、join數(shù)量和select列。舉個例子如果你明明只想查5個用戶Hibernate卻多出了一次對寵物表的join日志里就能看到兩個join t_pet這時候可以百分百斷定是隱性重復join或別名覆蓋問題。重點要看的是Hibernate生成的SQL別名像u1_0、p1_0這種與你定義的別名不是一回事。日志里出現(xiàn)u1_0不代表你的別名寫法錯了那只是Hibernate的“內部代號”。許多開發(fā)者在這里被誤導以為自己寫的別名導致SQL異常其實自己寫的別名早就被解析成內部代號了。我個人在實際操作中的體會是寫HQL前先給實體起好別名并且從第一條where到最后一條order都只引用這個別名絕不混用另一個臨時稱呼寫原生SQL時凡是結果要映射回實體或DTO的列全部顯式加as 目標屬性名寫Criteria時堅持用一個join變量貫穿查詢不重復創(chuàng)建關聯(lián)路徑。這套規(guī)矩看著樸素但能避免掉絕大多數(shù)別名相關的坑比記住什么“隱式別名”“顯式別名”的概念都管用。