之前網上購買了一套springmvc+hibernate+mybatis+shiro等常用框架整合的系統原始碼。搭建好環境，跑起來後發現不錯，辦公的基本功能都有。
於是就把公司現在oa系統的使用者匯入了新系統。總共也就匯入了1000多條資料，然後發現系統執行的沒那麼流暢了。
尤其是使用者管理頁面，分頁查詢才顯示10條記錄，需要耗時40秒左右。於是debug弄了一下午，終於找到原因了。
下面是除錯發現的查詢的criteria：
criteriaimpl(com.framework.sys.entity.user:this[subcriteria(company:company), subcriteria(office:office)][office.id=1 or office.parentids like %,1,%, (), delflag=0])
select userlist0_.role_id as role_id2_102_4_, userlist0_.user_id as user_id1_106_4_, user1_.id as id1_105_0_, user1_.create_by as create_17_105_0_, user1_.create_date as create_d2_105_0_, user1_.del_flag as del_flag3_105_0_, user1_.remarks as remarks4_105_0_, user1_.update_by as update_18_105_0_, user1_.update_date as update_d5_105_0_, user1_.company_id as company19_105_0_, user1_.email as email6_105_0_, user1_.login_date as login_da7_105_0_, user1_.login_ip as login_ip8_105_0_, user1_.login_name as login_na9_105_0_, user1_.mobile as mobile10_105_0_, user1_.name as name11_105_0_, user1_.no as no12_105_0_, user1_.office_id as office_20_105_0_, user1_.password as passwor13_105_0_, user1_.phone as phone14_105_0_, user1_.photo as photo15_105_0_, user1_.user_type as user_ty16_105_0_, office2_.id as id1_101_1_, office2_.create_by as create_17_101_1_, office2_.create_date as create_d2_101_1_, office2_.del_flag as del_flag3_101_1_, office2_.remarks as remarks4_101_1_, office2_.update_by as update_18_101_1_, office2_.update_date as update_d5_101_1_, office2_.address as address6_101_1_, office2_.area_id as area_id19_101_1_, office2_.code as code7_101_1_, office2_.email as email8_101_1_, office2_.fax as fax9_101_1_, office2_.grade as grade10_101_1_, office2_.master as master11_101_1_, office2_.name as name12_101_1_, office2_.parent_id as parent_20_101_1_, office2_.parent_ids as parent_13_101_1_, office2_.phone as phone14_101_1_, office2_.type as type15_101_1_, office2_.zip_code as zip_cod16_101_1_, area3_.id as id1_96_2_, area3_.create_by as create_10_96_2_, area3_.create_date as create_d2_96_2_, area3_.del_flag as del_flag3_96_2_, area3_.remarks as remarks4_96_2_, area3_.update_by as update_11_96_2_, area3_.update_date as update_d5_96_2_, area3_.code as code6_96_2_, area3_.name as name7_96_2_, area3_.parent_id as parent_12_96_2_, area3_.parent_ids as parent_i8_96_2_, area3_.type as type9_96_2_, office4_.id as id1_101_3_, office4_.create_by as create_17_101_3_, office4_.create_date as create_d2_101_3_, office4_.del_flag as del_flag3_101_3_, office4_.remarks as remarks4_101_3_, office4_.update_by as update_18_101_3_, office4_.update_date as update_d5_101_3_, office4_.address as address6_101_3_, office4_.area_id as area_id19_101_3_, office4_.code as code7_101_3_, office4_.email as email8_101_3_, office4_.fax as fax9_101_3_, office4_.grade as grade10_101_3_, office4_.master as master11_101_3_, office4_.name as name12_101_3_, office4_.parent_id as parent_20_101_3_, office4_.parent_ids as parent_13_101_3_, office4_.phone as phone14_101_3_, office4_.type as type15_101_3_, office4_.zip_code as zip_cod16_101_3_
from sys_user_role userlist0_
inner join sys_user user1_ on userlist0_.user_id=user1_.id
inner join sys_office office2_ on user1_.company_id=office2_.id
left outer join sys_area area3_ on office2_.area_id=area3_.id
inner join sys_office office4_ on user1_.office_id=office4_.id
where ( user1_.del_flag='0')
and userlist0_.role_id in (
select role1_.id from sys_user_role rolelist0_
inner join sys_role role1_ on rolelist0_.role_id=role1_.id
left outer join sys_office office2_ on role1_.office_id=office2_.id
left outer join sys_area area3_ on office2_.area_id=area3_.id
where ( role1_.del_flag='0') and rolelist0_.user_id in (
select this_.id from sys_user this_
inner join sys_office company1_ on this_.company_id=company1_.id
left outer join sys_area area5_ on company1_.area_id=area5_.id
inner join sys_office office2_ on this_.office_id=office2_.id
where (office2_.id=1 or office2_.parent_ids like '') and 1=1 and this_.del_flag=0 ) )
order by user1_.id
分析sql發現是從sys_user_role開始查詢，而使用者列表應該和角色沒關係才對啊。並且主要是後面那些in條件導致查詢變慢。但是根據criteriaimpl，並沒有設定那些篩選條件，為什麼會出現多層巢狀的in條件過濾呢？
最後發現是因為定義user和role實體中的註解@manytomany是兩邊都是定義的飢渴模式。把他們都改為lazy模式就好了。
但是@manytomany定義的飢渴模式時，好像即使有二級快取，每次查詢時依然會去資料庫中查詢，速度好慢。猜測可能飢渴模式會導致二級快取失效？
Hibernate效能優化
hibernate效能優化提高 1.快取 hibernate缺省會用到快取，用得好就能大大提高效能，用得不好就會影響到效率 快取其實就是資料庫資料在記憶體中的乙個臨時容器，將查詢過得資料暫時放在這個容器中，下次如果還是查詢一樣的，就直接在該容器中取得，就不用再去資料庫裡查詢了，這樣間接性的提高了效率...
HIBERNATE查詢效能
查詢效能往往是系統效能表現的乙個重要方面，查詢機制的優劣很大程度上決定了系統的整體效能。這個領域往往也存在最大的效能調整空間。hibernate2中session.find 對應於3中的session.createquery list hibernate2中session.iterate 對應於3中...
hibernate 查詢優化
1.延遲載入先獲取到 物件，當真正使用到該物件中的屬性的時候，才會傳送sql語句，是hibernate框架提公升效能的方式 2.類級別的延遲載入 session物件的load方法預設就是延遲載入 customer c session.load customer.class,1l 沒有傳送sql語句，...