兩張表 組織架構(gòu)表（Organise） 和 工資發(fā)放歷史記錄表 （WagePerMonthHis）
兩張表通過 Organise.Item_id 和 WagePerMonthHis.OrgIdS 進行關聯(lián)
Organise表(以下簡稱O表)中大約有6000條記錄11個字段 ,WagePerMonthHis(以下簡稱W表)計有 125萬條記錄 和 25個字段
原程序中一段如下的語句
是查詢所有不在W表的組織架構(gòu)層級為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
語句執(zhí)行要33秒之久,服務器的配置是比較高的:16核心4CPU,24G內(nèi)存,且內(nèi)存和CPU在執(zhí)行時都沒有出現(xiàn)瓶頸,開始以為是 (select OrgidS from WagesPerMonthHis
where WagesYear='2010' and WagesMonth=
'01' Group by OrgidS,OrgNameS) 這條語句執(zhí)行緩慢所致,單獨執(zhí)行這條卻發(fā)現(xiàn)執(zhí)行速度很快,大約不到2秒就出來了,于是癥結(jié)出來了,是not in 這個全掃描關鍵詞帶來的性能下降.最直接的是導致頁面失去響應,一個關鍵功能使用不了.
試了not exist語句,發(fā)現(xiàn)效果是一樣的,并不象網(wǎng)上所說可以提高很多性能.
于是重新優(yōu)化語句如下
復制代碼 代碼如下:
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 公司編碼
改用左外連接(其實左連接也可以)后,整個語句執(zhí)行速度為400ms, 33秒與400ms 我想是很多人沒想到的.
您可能感興趣的文章:- php對外發(fā)包引發(fā)服務器崩潰的終極解決方法分享[推薦]
- linux下監(jiān)視進程 崩潰掛掉后自動重啟的shell腳本
- Android 如何收集已發(fā)布程序的崩潰信息
- js中關于一個分號的崩潰示例
- jquery.uploadify插件在chrome瀏覽器頻繁崩潰解決方法
- iOS 捕獲程序崩潰日志
- 數(shù)據(jù)庫崩潰，利用備份和日志進行災難恢復
- 詳解Android中處理崩潰異常
- Android實現(xiàn)將應用崩潰信息發(fā)送給開發(fā)者并重啟應用的方法
- 解決iOS7上UITextField限制字數(shù)輸入導致崩潰問題的方法
