這個時候，比較sql1和sql2和sql3的效率就會大大提高，雖然sql1 和 sql2兩個數(shù)組的長度相等，還是要一個元素一個元素的比較，但由于里面大量用到了String常量，相同的String常量具有相同的reference，所以5步下來，就可以判斷出sql1和sql2數(shù)組的元素是完全相等的；4步下來，加上第一個字符的比較，就可以判斷sql1和sql3的第4個元素是不相等的。
我們看到，做法1和做法2，能夠100%的提高SQL的比較效率，大部分情況下，也許比parameters的比較還快。
三、定長預(yù)取
多用戶訪問同一頁面的可能性比較大的情況下，比如，論壇的某些熱門話題，很可能被多人同時翻閱。這時候，如果把根據(jù)范圍取出的數(shù)據(jù)對象List也按照QueryKey存入緩存中，那么就可以大大提高響應(yīng)速度，減輕數(shù)據(jù)服務(wù)器負擔，當然，你的Web Server的內(nèi)存負擔也大大增加了。
我們進一步考慮下面兩種情況：
1. 用戶自定義頁面記錄數(shù)
一般來說，用戶可以自定義自己的每頁顯示記錄個數(shù)，比如，有些用戶喜歡每頁20條，有的喜歡每頁10條。
假設(shè)用戶A翻到一個論壇的第一頁，顯示1 – 20條信息；用戶B翻到同一個論壇的第一頁，顯示1 – 10條信息。這個時候，緩存的命中率是很低的。用戶A和用戶B無法共享緩存信息。因為他們的range(的span)總是不同，QueryKey永遠不可能相同。
2. 記錄很多、每頁記錄數(shù)過少
假設(shè)一個論壇里面有1000條信息，每頁顯示10條，那么共有100頁。如果用戶一頁一頁的翻動，每次程序發(fā)出一個span大小為10的Query請求，取出10條記錄，根據(jù)QueryKey緩存起來。由于頁面記錄數(shù)過少，每次數(shù)據(jù)庫查詢的效率很低，緩存命中率也很低。
為了提高緩存命中率，并且順便實現(xiàn)數(shù)據(jù)預(yù)取功能，我們可以采取 同一定長Span的方案。比如，還是上面的例子，我們在程序中設(shè)定統(tǒng)一Span大小為100。
當用戶A請求1 – 10的記錄的時候，程序判斷這個落在 1 – 100的范圍內(nèi)，那么用range (1, 100)獲取100條記錄，把前面的10條返回給用戶。當用戶A翻了一頁，請求11 – 20的記錄的時候，程序判斷還是落在 1 – 100的范圍內(nèi)，而且已經(jīng)存在于緩存中，那么直接把對應(yīng)的11 – 20條返回給用戶A就可以。
當用戶B 請求1 – 20的記錄的時候，程序判斷這個落在 1 – 100的范圍內(nèi)，而且已經(jīng)存在于緩存中，那么直接把對應(yīng)的1 – 20條返回給用戶B就可以。
可以看到，這種定長預(yù)取方案能夠大大提高數(shù)據(jù)庫查詢的效率和緩存的命中率。
關(guān)于Cache & QueryKey 部分，偶有1個問題：你是如何做到cache的自動清理和聰明地清理？
舉個例子
假設(shè)有這樣的查詢語句：select * from message where message_to = ?
執(zhí)行了2次值不同的操作：'buaawhl' 和 'Readonly'
那么就有2個不同QueryKey對應(yīng)到Cache里的對象。
這個時候再執(zhí)行一個write的操作：往message表里面插入了一條message_to等于‘buaawhl’的記錄，那么之前在Cache里QueryKey為'buaawhl'的對象會不會自動失效？而QueryKey為'Readonly'的對象是否還能保持有效呢？
沒有這么智能。我現(xiàn)在無法做到 cache的自動清理和聰明地清理。
我現(xiàn)在做的持久層本身是不做cache的清理管理工作，這個工作交給 調(diào)用程序自己去做。cache也需要用戶自己實現(xiàn)，并且明確提供。
查詢的時候，需要指定cache
| java代碼: |
|
finder.setRowClass(Message.class);
finder.setCache(cache);
finder.queryRowsRange(conP, sql, params, offset, span);
|
這個時候，finder會用 QueryKey(sql, params, offset, span) 作為Key,
從指定的cache里面，查找對應(yīng)的記錄集合。
如果查不到，從conP真正獲取一個connection，連接并查找數(shù)據(jù)庫，把結(jié)果放到cache里面。
這里有個優(yōu)化，如果指定了緩存，而且只有當緩存中不存在目標數(shù)據(jù)的時候，才真正地從連接池中獲取connection。主要是考慮到連接池的大小總是有限的，如果并發(fā)用戶多的話，這樣就可以節(jié)省連接池里的connection的分配。
---
update, delete, update的時候，用戶需要手動自己清理cache的內(nèi)容。
| java代碼: |
|
persister.insertRow(con, message);
cache.clear();
// 或者更智能的操作, 比如, 根據(jù)message的message_to value,
// 清理Cache里面的符合下列條件的QueryKey
// (sql 包含 message_to = ?, 并且 params[0] = buaawhl)
|
我做的持久層，由于直接使用SQL，在 自動智能過濾緩存數(shù)據(jù) 方面，具有先天的缺陷。
因為SQL可以寫的很復(fù)雜，比HQL復(fù)雜很多。而且還有各種 Native SQL特性，沒有一個統(tǒng)一的中間語言（比如HQL）， 解析起來也相當復(fù)雜。
即使有這么一個中間語言，解析處理的代價和難度也相當大。相當于實現(xiàn)了一個小型的HSQL級別的內(nèi)存數(shù)據(jù)庫。
而對于用戶來說，定義DAO方法的時候，很清楚自己SQL的語義，實現(xiàn)智能緩存處理更容易一些，所以干脆把cache的管理交給用戶自己。
這樣做的另一個目的是，我想把 對應(yīng)的頁面緩存也放到同一個cache中去。
還有一種情況，比如，user, group, group user, 三個不同的Data Object類，由于相互關(guān)聯(lián)，那么用戶可以指定這三個類使用同一個cache，簡化管理。
還有一種情況，比如，我想用message類，同時對應(yīng) 站內(nèi)短信，和論壇帖子兩個對象，我也可以為這兩種不同的情況，指定不同cache。
---
Hibernate如果想實現(xiàn) 自動智能過濾緩存數(shù)據(jù) 方面，那么具有天生的優(yōu)勢。
因為本來Hibernate就是要 解析HQL的，而且Hibernate管理數(shù)據(jù)類本身及其之間的關(guān)聯(lián)。什么信息都有了，做起來也相對容易很多。
當然Hibernate并沒有做這個工作。Hibernate只提供了一個evictQueries()方法，不分類型地清理所有的cached query.
Hibernate的QueryKey也是直接使用結(jié)果SQL，而不是HQL。
| java代碼: |
|
// from hibernate 2.7
public class QueryKey implements Serializable {
private final String sqlQueryString;
private final Type[] types;
private final Object[] values;
private final Integer firstRow;
private final Integer maxRows;
private final Map namedParameters;
...
public boolean equals(Object other) {
QueryKey that = (QueryKey) other;
if ( !sqlQueryString.equals(that.sqlQueryString) ) return false;
if ( !EqualsHelper.equals(firstRow, that.firstRow) || !EqualsHelper.equals(maxRows, that.maxRows) ) return false;
...
return true;
}
|
可以看到，hibernate query key 直接比較結(jié)果SQL。而且我們知道，這個SQL是HQL轉(zhuǎn)換過來的結(jié)果，reference一定不會相等。
假設(shè)這個SQL很長的時候，而兩個SQL又相同，這個比較就會比較消耗時間。而且，這個QueryKey占的空間也比較大。
（在我的持久層里面，SQL盡量采用常量字符串、或常量字符串數(shù)組，在一定程度上解決這個問題。當然，這需要用戶在使用的時候，有意識的支持）
我想了一下，為什么hibernate QueryKey直接采用結(jié)果SQL，而不用HQL。
這個SQL是HQL的解析結(jié)果，直接使用結(jié)果，節(jié)省了解析時間。比如，F(xiàn)rom A where id = 1 和 from A WHERE ID = '1'，兩個HQL字符串不相同，但語義相同，轉(zhuǎn)換出來的SQL一定相同。
如果Hibernate要加入智能管理QueryCache的功能，需要在QueryKey里面加入更多的信息（比如，HQL的解析結(jié)果的條件過濾部分），這樣QueryKey的占用空間就會進一步加大。
有一個hibernate cache討論。
http://forum.javaeye.com/viewtopic.php?t=6593
我的另一個帖子里面也有介紹。
http://forum.javaeye.com/viewtopic.php?t=9706
Hibernate主要的緩存是ID緩存（二級緩存），而QueryCache緩存的支持非常初級。
ID緩存的Key非常簡單，就是persistent class + entity identifier。
具體來說，每個不同的persistent class有獨立的ID緩存，該獨立ID緩存的key就是 entity identifier。
ID緩存的管理是不是在 Method Interceptor里面管理的。我從hibernate代碼中看不出這一點。也許在Hibernate自定義的Event中處理。
我大致猜測一下，Hibernate把updated, inserted, deleted Entities(對于用戶來說，就是PO；對于Hibernate來說，就是Entity, Proxy)都保存在內(nèi)部的一個Collection結(jié)構(gòu)里面。在最后Session.flush()的時候，統(tǒng)一處理，同步更新數(shù)據(jù)庫狀態(tài)，和ID緩存狀態(tài)。