兩張表 組織架構表(Organise) 和 工資發放記錄表 (WagePerMonthHis)
兩張表通過 Organise.Item_id 和 WagePerMonthHis.OrgIdS 進行關聯
Organise表(以下簡稱O表)中大約有6000條記錄11個欄位 ,WagePerMonthHis(以下簡稱W表)計有 125萬條記錄 和 25個欄位
原程式中一段如下的語句
是查詢所有不在W表的組織架構層級為2的記錄 複製代碼 代碼如下:select OrgId as 公司編碼,OrgName as 公司名稱
from Organise
where OrgLev=2
and item_id not in
(select OrgidS from WagesPerMonthHis
where WagesYear='2010' and WagesMonth=
'01' Group by OrgidS,OrgNameS)
order by Orgid
語句執行要33秒之久,伺服器的配置是比較高的:16核心4CPU,24G記憶體,且記憶體和CPU在執行時都沒有出現瓶頸,開始以為是 (select OrgidS from WagesPerMonthHis
where WagesYear='2010' and WagesMonth=
'01' Group by OrgidS,OrgNameS) 這條語句執行緩慢所致,單獨執行這條卻發現執行速度很快,大約不到2秒就出來了,於是癥結出來了,是not in 這個全掃描關鍵詞帶來的效能下降.最直接的是導致頁面失去響應,一個關鍵功能使用不了.
試了not exist語句,發現效果是一樣的,並不象網上所說可以提高很多效能.
於是重新最佳化語句如下 複製代碼 代碼如下:select a.OrgId as 公司編碼,a.OrgName as 公司名稱,a.item_id
from Organise a
left outer join (select distinct b.OrgIdS from WagesPerMonthHis b
where WagesYear='2010' and WagesMonth='01') as b
on a.item_id = b.OrgidS
where a.OrgLev = 2
and b.OrgIdS is Null
order by 公司編碼
改用左外串連(其實左串連也可以)後,整個語句執行速度為400ms, 33秒與400ms 我想是很多人沒想到的.