針對昨天同事遇到的hibernate的問題。算是hibernate最基本的東西。具了解，這個問題很多人遇到過，也很常見，卻遇到了還經(jīng)常會懵了。

為了加深印象，知其然，知其所以然。

之后單純用原始的Hibernate框架做了一些驗證，并且打開執(zhí)行SQL打印輸出臺的，得出的結(jié)論：

前提是在同一事務中間：

1、利用sql語句， session.createSQLQuery(sql).executeUpdate();進行插入，輸出臺打印出sql插入語句； 再利用sql語句，進行session.createSQLQuery(sql).uniqueResult(); 也會打印SQL查詢語句，沒有問題，可以查詢到數(shù)據(jù)。

2、利用hibernate封裝操作， session.save(entity); 進行插入，輸出臺并沒有打印出插入的SQL語句， 再利用 session.get(entity,id);方法做查詢 ；也沒有打印出SQL查詢語句，但是是可以查詢到數(shù)據(jù)的。到執(zhí)行事務提交語句時，插入的SQL語句被打印出來

3、利用hibernate的session.save(entity); 進行插入，再利用《HQL》語句進行查詢，效果同上面第二點。

4、利用hibernate的session.save(entity); 進行插入，輸出臺并沒有打印出插入的SQL語句。 再利用sql語句，進行session.createSQLQuery(sql).uniqueResult(); 會打印SQL查詢語句。問題出現(xiàn)了，查詢不到任何數(shù)據(jù)。這種情況下利用session.flush()方法，在查詢之前執(zhí)行到flush()方法，輸出臺會打印出插入的SQL語句。 再進行查詢就有數(shù)據(jù)。

驗證完成之后，查了下往上資料，對于第四點，在開發(fā)過程中出現(xiàn)頻繁，非常的常見，相信很多人都曾遇到，但又有很多人繼續(xù)摸不到頭腦。正好以此加深了印象。

從打印控制臺SQL可以看出一個基本的hibernate save方法的操作流程：

1． 判斷所要保存的實例是否已處于持久化狀態(tài)，如果不是，則將其置入緩存；

2． 根據(jù)所要保存的實例計劃一條insert sql語句，注意只是計劃，并不執(zhí)行；

3． 事務提交時執(zhí)行之前所計劃的insert語句；

將tx.commit()換成session.flush，此時控制太打印出了insert語句，但是數(shù)據(jù)庫中并沒有添加新的記錄；

flush方法的主要作用就是清理緩存，強制數(shù)據(jù)庫與Hibernate緩存同步，以保證數(shù)據(jù)的一致性。它的主要動作就是向數(shù)據(jù)庫發(fā)送一系列的sql語句，并執(zhí)行這些sql語句，但是不會向數(shù)據(jù)庫提交。而commit方法則會首先調(diào)用flush方法，然后提交事務。這就是為什么我們僅僅調(diào)用flush的時候記錄并未插入到數(shù)據(jù)庫中的原因，因為只有提交了事務，對數(shù)據(jù)庫所做的更新才會被保存下來。因為commit方法隱式的調(diào)用了flush，所以一般我們都不會顯示的調(diào)用flush方法。

這是hibernate的flush機制。在一些復雜的對象更新和保存的過程中就要考慮數(shù)據(jù)庫操作順序的改變以及延時flush是否對程序的結(jié)果有影響。如果確實存在著影響，那就可以在需要保持這種操作順序的位置加入flush強制Hibernate將緩存中記錄的操作flush入數(shù)據(jù)庫，這樣看起來也許不太美觀，但很有效。

疑問：session.save方法，放入緩存中，SQL直接查詢數(shù)據(jù)庫是查不出來的。

flush()方法之后，會打印出執(zhí)行SQL，但是數(shù)據(jù)庫中，還是沒有。SQL直接查詢卻能查出數(shù)據(jù)來。

1、flush() 之后這個實體數(shù)據(jù)存放在什么地方？和save()方法一樣的緩存，那SQL也應該是取不到的。

2、既然flush方法之后數(shù)據(jù)沒有進數(shù)據(jù)庫，SQL直接查詢，利用session.createSQLQuery(sql) 查詢，直接查得應該不是數(shù)據(jù)庫，他查詢的又是什么地方？