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