『壹』 hql與sql哪個查詢速度快

你是想比較JDBC的SQL和Hibernate的HQL嗎?

HIBERNATE最後還是會把數據操作轉換成SQL語句通過JDBC發送給DB。
理論上來說,HIBERNATE還多了轉換為SQL的操作,會比直接寫SQL要多消耗資源。
但事實上HIBERNATE做了一些優化,使用緩存、連接池和臟數據檢查等技術來提高速度,而且全是對象化操作,不用感受寫大量SQL的痛苦,會比自己寫SQL要好很多(除非你是資料庫開發的高手,則例外)。

『貳』 急:Hibernate 的hql優缺點

Hibernate優點:(1)對象/關系資料庫映射(Basic O/R Mapping)它使用時只需要操縱對象,使開發更對象化,拋棄了資料庫中心的思想,完全的面向對象思想。(2)透明持久化(Persistent) 帶有持久化狀態的、具有業務功能的單線程對象,此對象生存期很短。這些對象可能是普通的javaBeans/POJO,這個對象沒有實現第三方框架或者介面,唯一特殊的是他們正與(僅僅一個)Session相關聯。一旦這個Session被關閉,這些對象就會脫離持久化狀態,這樣就可被應用程序的任何層自由使用。(例如,用作跟表示層打交道的數據傳輸對象。) (3)事務Transaction (org.Hibernate.Transaction)應用程序用來指定原子操作單元范圍的對象,它是單線程的,生命周期很短。它通過抽象將應用從底層具體的JDBC、JTA以及CORBA事務隔離開。某些情況下,一個Session之內可能包含多個Transaction對象。盡管是否使用該對象是可選的,但無論是使用底層的API還是使用Transaction對象,事務邊界的開啟與關閉是必不可少的。 (4)它沒有侵入性,即所謂的輕量級框架。 (5)移植性會很好。 (6)緩存機制。提供一級緩存和二級緩存。 (7)簡潔的HQL編程。2.Hibernate缺點:(1)Hibernate在批量數據處理的時候是有弱勢。(2)針對某一對象(單個對象)簡單的查\改\刪\增,不是批量修改、刪除,適合用Hibernate;而對於批量修改、刪除,不適合用Hibernate,這也是OR框架的弱點;要使用資料庫的特定優化機制的時候,不適合用Hibernate。以上便是我所熟悉的Hibernate的優缺點。

『叄』 高手幫我把這條HQL語句優化一下吧,在線等。。。。。。

from 表名 as t where pingJiFH <> (select tt.pingJiFH 表名 as tt where tt.時間欄位=去年)
不懂追問!!

『肆』 HQL代碼優化 JAVA

from SelectOP where 1=1 and where joinNames in(:xxx)

『伍』 HQL優化從哪幾個方面考慮

首先是 從程序條件,對語句的簡寫,就是不使用hql語句哦使用sql語句,要不使用存儲過城來查詢

『陸』 hibernate hql 語句中inner join三表查詢如何寫以及hibernate hql中的in子查詢如何優化

hibernate做這種查詢性能不到。 要記住hibernate自帶了一、二級緩存。而它還有封裝結果集成對專象。
所以,我屬推薦使用hibernate的sqlquery。或者最好直接用connection、result、statement

『柒』 hibernate如何優化大數據量操作

建議你直接用Jdbc好了,用batch,這樣是最快的。

『捌』 java項目,oracle百萬數據優化,hql語句優化

索引不能建在有空值的欄位上,分析具體日誌中的sql, 不知道hql中是否能加hint,/*first_rows(行數)*/,這樣能提升速度

『玖』 如何優化hibernate框架的使用

初用HIBERNATE的人也許都遇到過性能問題,實現同一功能,用HIBERNATE與用JDBC性能相差十幾倍很正常,如果不及早調整,很可能影響整個項目的進度。
大體上,對於HIBERNATE性能調優的主要考慮點如下:

* 資料庫設計調整

*HQL優化

* API的正確使用(如根據不同的業務類型選用不同的集合及查詢API)

* 主配置參數(日誌,查詢緩存,fetch_size, batch_size等)

* 映射文件優化(ID生成策略,二級緩存,延遲載入,關聯優化)

* 一級緩存的管理

* 針對二級緩存,還有許多特有的策略

* 事務控制策略。

1、 資料庫設計

a) 降低關聯的復雜性

b) 盡量不使用聯合主鍵

c) ID的生成機制,不同的資料庫所提供的機制並不完全一樣

d) 適當的冗餘數據,不過分追求高範式

2、 HQL優化

HQL如果拋開它同HIBERNATE本身一些緩存機制的關聯,HQL的優化技巧同普通的SQL優化技巧一樣,可以很容易在網上找到一些經驗之談。

3、 主配置

a) 查詢緩存,同下面講的緩存不太一樣,它是針對HQL語句的緩存,即完全一樣的語句再次執行時可以利用緩存數據。但是,查詢緩存在一個交易系統(數據變更頻繁,查詢條件相同的機率並不大)中可能會起反作用:它會白白耗費大量的系統資源但卻難以派上用場。

b) fetch_size,同JDBC的相關參數作用類似,參數並不是越大越好,而應根據業務特徵去設置

c) batch_size同上。

d) 生產系統中,切記要關掉SQL語句列印。

4、 緩存

a) 資料庫級緩存:這級緩存是最高效和安全的,但不同的資料庫可管理的層次並不一樣,比如,在ORACLE中,可以在建表時指定將整個表置於緩存當中。

b) SESSION緩存:在一個HIBERNATE SESSION有效,這級緩存的可干預性不強,大多於HIBERNATE自動管理,但它提供清除緩存的方法,這在大批量增加/更新操作是有效的。比如,同時增加十萬條記錄,按常規方式進行,很可能會發現OutofMemeroy的異常,這時可能需要手動清除這一級緩存:Session.evict以及Session.clear

c) 應用緩存:在一個SESSIONFACTORY中有效,因此也是優化的重中之重,因此,各類策略也考慮的較多,在將數據放入這一級緩存之前,需要考慮一些前提條件:

i. 數據不會被第三方修改(比如,是否有另一個應用也在修改這些數據?)

ii. 數據不會太大

iii. 數據不會頻繁更新(否則使用CACHE可能適得其反)

iv. 數據會被頻繁查詢

v. 數據不是關鍵數據(如涉及錢,安全等方面的問題)。

緩存有幾種形式,可以在映射文件中配置:read-only(只讀,適用於很少變更的靜態數據/歷史數據),nonstrict-read-write,read-write(比較普遍的形式,效率一般),transactional(JTA中,且支持的緩存產品較少)

d) 分布式緩存:同c)的配置一樣,只是緩存產品的選用不同,在目前的HIBERNATE中可供選擇的不多,oscache, jboss cache,目前的大多數項目,對它們的用於集群的使用(特別是關鍵交易系統)都持保守態度。在集群環境中,只利用資料庫級的緩存是最安全的。

5、 延遲載入

a) 實體延遲載入:通過使用動態代理實現

b) 集合延遲載入:通過實現自有的SET/LIST,HIBERNATE提供了這方面的支持

c) 屬性延遲載入:

6、 方法選用

a) 完成同樣一件事,HIBERNATE提供了可供選擇的一些方式,但具體使用什麼方式,可能用性能/代碼都會有影響。顯示,一次返回十萬條記錄(List/Set/Bag/Map等)進行處理,很可能導致內存不夠的問題,而如果用基於游標(ScrollableResults)或Iterator的結果集,則不存在這樣的問題。

b) Session的load/get方法,前者會使用二級緩存,而後者則不使用。

c) Query和list/iterator,如果去仔細研究一下它們,你可能會發現很多有意思的情況,二者主要區別(如果使用了Spring,在HibernateTemplate中對應find,iterator方法):

i. list只能利用查詢緩存(但在交易系統中查詢緩存作用不大),無法利用二級緩存中的單個實體,但list查出的對象會寫入二級緩存,但它一般只生成較少的執行SQL語句,很多情況就是一條(無關聯)。

ii. iterator則可以利用二級緩存,對於一條查詢語句,它會先從資料庫中找出所有符合條件的記錄的ID,再通過ID去緩存找,對於緩存中沒有的記錄,再構造語句從資料庫中查出,因此很容易知道,如果緩存中沒有任何符合條件的記錄,使用iterator會產生N+1條SQL語句(N為符合條件的記錄數)

iii. 通過iterator,配合緩存管理API,在海量數據查詢中可以很好的解決內存問題,如:

while(it.hasNext()){

YouObject object = (YouObject)it.next();

session.evict(youObject);

sessionFactory.evice(YouObject.class, youObject.getId());

}

如果用list方法,很可能就出OutofMemory錯誤了。

iv. 通過上面的說明,我想你應該知道如何去使用這兩個方法了。

7、 集合的選用

在HIBERNATE 3.1文檔的「19.5. Understanding Collection performance」中有詳細的說明。

8、 事務控制

事務方面對性能有影響的主要包括:事務方式的選用,事務隔離級別以及鎖的選用

a) 事務方式選用:如果不涉及多個事務管理器事務的話,不需要使用JTA,只有JDBC的事務控制就可以。

b) 事務隔離級別:參見標準的SQL事務隔離級別

c) 鎖的選用:悲觀鎖(一般由具體的事務管理器實現),對於長事務效率低,但安全。樂觀鎖(一般在應用級別實現),如在HIBERNATE中可以定義VERSION欄位,顯然,如果有多個應用操作數據,且這些應用不是用同一種樂觀鎖機制,則樂觀鎖會失效。因此,針對不同的數據應有不同的策略,同前面許多情況一樣,很多時候我們是在效率與安全/准確性上找一個平衡點,無論如何,優化都不是一個純技術的問題,你應該對你的應用和業務特徵有足夠的了解。

9、 批量操作

即使是使用JDBC,在進行大批數據更新時,BATCH與不使用BATCH有效率上也有很大的差別。我們可以通過設置batch_size來讓其支持批量操作。

舉個例子,要批量刪除某表中的對象,如「delete Account」,打出來的語句,會發現HIBERNATE找出了所有ACCOUNT的ID,再進行刪除,這主要是為了維護二級緩存,這樣效率肯定高不了,在後續的版本中增加了bulk delete/update,但這也無法解決緩存的維護問題。也就是說,由於有了二級緩存的維護問題,HIBERNATE的批量操作效率並不盡如人意!