sqlserver not in 語句使程充崩潰
更新時(shí)間：2011年12月17日 01:52:04 作者：
以前一直以為優(yōu)化在百萬級的表中才會(huì)有意義，這次的事件改變了我的看法
兩張表 組織架構(gòu)表（Organise） 和 工資發(fā)放歷史記錄表 （WagePerMonthHis）
兩張表通過 Organise.Item_id 和 WagePerMonthHis.OrgIdS 進(jìn)行關(guān)聯(lián)
Organise表(以下簡稱O表)中大約有6000條記錄11個(gè)字段 ,WagePerMonthHis(以下簡稱W表)計(jì)有 125萬條記錄 和 25個(gè)字段
原程序中一段如下的語句
是查詢所有不在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秒之久,服務(wù)器的配置是比較高的:16核心4CPU,24G內(nèi)存,且內(nèi)存和CPU在執(zhí)行時(shí)都沒有出現(xiàn)瓶頸,開始以為是 (select OrgidS from WagesPerMonthHis
where WagesYear='2010' and WagesMonth=
'01' Group by OrgidS,OrgNameS) 這條語句執(zhí)行緩慢所致,單獨(dú)執(zhí)行這條卻發(fā)現(xiàn)執(zhí)行速度很快,大約不到2秒就出來了,于是癥結(jié)出來了,是not in 這個(gè)全掃描關(guān)鍵詞帶來的性能下降.最直接的是導(dǎo)致頁面失去響應(yīng),一個(gè)關(guān)鍵功能使用不了.
試了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 公司編碼
改用左外連接(其實(shí)左連接也可以)后,整個(gè)語句執(zhí)行速度為400ms, 33秒與400ms 我想是很多人沒想到的.
兩張表通過 Organise.Item_id 和 WagePerMonthHis.OrgIdS 進(jìn)行關(guān)聯(lián)
Organise表(以下簡稱O表)中大約有6000條記錄11個(gè)字段 ,WagePerMonthHis(以下簡稱W表)計(jì)有 125萬條記錄 和 25個(gè)字段
原程序中一段如下的語句
是查詢所有不在W表的組織架構(gòu)層級為2的記錄
復(fù)制代碼 代碼如下:
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秒之久,服務(wù)器的配置是比較高的:16核心4CPU,24G內(nèi)存,且內(nèi)存和CPU在執(zhí)行時(shí)都沒有出現(xiàn)瓶頸,開始以為是 (select OrgidS from WagesPerMonthHis
where WagesYear='2010' and WagesMonth=
'01' Group by OrgidS,OrgNameS) 這條語句執(zhí)行緩慢所致,單獨(dú)執(zhí)行這條卻發(fā)現(xiàn)執(zhí)行速度很快,大約不到2秒就出來了,于是癥結(jié)出來了,是not in 這個(gè)全掃描關(guān)鍵詞帶來的性能下降.最直接的是導(dǎo)致頁面失去響應(yīng),一個(gè)關(guān)鍵功能使用不了.
試了not exist語句,發(fā)現(xiàn)效果是一樣的,并不象網(wǎng)上所說可以提高很多性能.
于是重新優(yōu)化語句如下
復(fù)制代碼 代碼如下:
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 公司編碼
改用左外連接(其實(shí)左連接也可以)后,整個(gè)語句執(zhí)行速度為400ms, 33秒與400ms 我想是很多人沒想到的.
您可能感興趣的文章:
- php對外發(fā)包引發(fā)服務(wù)器崩潰的終極解決方法分享[推薦]
- linux下監(jiān)視進(jìn)程 崩潰掛掉后自動(dòng)重啟的shell腳本
- Android 如何收集已發(fā)布程序的崩潰信息
- js中關(guān)于一個(gè)分號的崩潰示例
- jquery.uploadify插件在chrome瀏覽器頻繁崩潰解決方法
- iOS 捕獲程序崩潰日志
- 數(shù)據(jù)庫崩潰，利用備份和日志進(jìn)行災(zāi)難恢復(fù)
- 詳解Android中處理崩潰異常
- Android實(shí)現(xiàn)將應(yīng)用崩潰信息發(fā)送給開發(fā)者并重啟應(yīng)用的方法
- 解決iOS7上UITextField限制字?jǐn)?shù)輸入導(dǎo)致崩潰問題的方法
相關(guān)文章
sqlserver 數(shù)據(jù)庫壓縮與數(shù)據(jù)庫日志(ldf)壓縮方法分享
數(shù)據(jù)庫在使用中，冗余的數(shù)據(jù)不斷的增加（數(shù)據(jù)刪除也不會(huì)減小），導(dǎo)致數(shù)據(jù)庫不斷的增大！所以該給你的數(shù)據(jù)庫減減肥了2011-12-12
如何創(chuàng)建支持FILESTREAM的數(shù)據(jù)庫示例探討
FILESTREAM使用一種特殊類型的文件組，因此在創(chuàng)建數(shù)據(jù)庫時(shí)，必須至少為一個(gè)文件組指定 CONTAINS FILESTREAM 子句接下來為你詳細(xì)介紹下如何創(chuàng)建支持 FILESTREAM 的數(shù)據(jù)庫2013-03-03
SQL?Server數(shù)據(jù)庫生成與執(zhí)行SQL腳本詳細(xì)教程
為了方便可以把需要連續(xù)執(zhí)行的SQL語句寫到一個(gè)文本文件中,并且用.SQL作為擴(kuò)展名,這種文件叫做SQL腳本文件,下面這篇文章主要給大家介紹了關(guān)于SQL?Server數(shù)據(jù)庫生成與執(zhí)行SQL腳本的相關(guān)資料,需要的朋友可以參考下2023-01-01
這篇文章主要介紹了sqlserver2017共享功能目錄路徑不可改的解決方法，文中通過圖文介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-04-04
數(shù)據(jù)庫性能優(yōu)化三：程序操作優(yōu)化提升性能
程序訪問優(yōu)化也可以認(rèn)為是訪問SQL語句的優(yōu)化，一個(gè)好的SQL語句是可以減少非常多的程序性能的，下面列出常用錯(cuò)誤習(xí)慣，并且提出相應(yīng)的解決方案2013-01-01
繼SQl -Function創(chuàng)建函數(shù)數(shù)據(jù)庫輸出的結(jié)果用逗號隔開，在開發(fā)中也有許多以參數(shù)的形式傳入帶逗號字條串參數(shù),需要的朋友可以參考下2016-10-10
積分獲取和消費(fèi)的存儲過程學(xué)習(xí)示例
這篇文章主要介紹了積分獲取和消費(fèi)的存儲過程學(xué)習(xí)示例，這個(gè)只是學(xué)習(xí)一下存儲過程的使用方法,需要的朋友可以參考下2014-03-03
這篇文章主要介紹了聚集索引和非聚集索引的相關(guān)知識，比較詳細(xì)整理了一些知識點(diǎn),需要的朋友可以參考下2014-07-07
當(dāng)需要的結(jié)果需要經(jīng)過多次處理后才能最終得到我們需要的結(jié)果時(shí)，就可以使用臨時(shí)表，這里臨時(shí)表就起到了一個(gè)中間處理的作用，實(shí)現(xiàn)了分步處理，簡化了問題，這篇文章主要介紹了sql語句中臨時(shí)表使用方法,需要的朋友可以參考下2023-02-02
這篇文章主要介紹了SQL 將一列拆分成多列的方法，文中講解非常細(xì)致，代碼幫助大家更好的理解和學(xué)習(xí)，感興趣的朋友可以了解下2020-07-07