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

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

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

　　前提是在同一事務中間：

　　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是否對程序的結果有影響。如果確實存在著影響，那可以在需要保持這種操作順序的位置加入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ù)庫，他查詢的又是什么地方？