[轉(zhuǎn)帖]SQL Server中存儲過程比直接運(yùn)行SQL語句慢的原因
當(dāng)前位置:點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
:SQL Server中存儲過程比直接運(yùn)行SQL語句慢的原因 在很多的資料中都描述說SQLSERVER的存儲過程較普通的SQL語句有以下優(yōu)點(diǎn): 1. 存儲過程只在創(chuàng)造時(shí)進(jìn)行編譯即可,以后每次執(zhí)行存儲過程都不需再重新編譯,而我們通常使用的SQL語句每執(zhí)行一次就編譯一次,所以使用存儲過程可提高數(shù)據(jù)庫執(zhí)行速度。 2. 經(jīng)常會遇到復(fù)雜的業(yè)務(wù)邏輯和對數(shù)據(jù)庫的操作,這個(gè)時(shí)候就會用SP來封裝數(shù)據(jù)庫操作。當(dāng)對數(shù)據(jù)庫進(jìn)行復(fù)雜操作時(shí)(如對多個(gè)表進(jìn)行 Update,Insert,Query,Delete時(shí)),可將此復(fù)雜操作用存儲過程封裝起來與數(shù)據(jù)庫提供的事務(wù)處理結(jié)合一起使用??梢詷O大的提高數(shù)據(jù) 庫的使用效率,減少程序的執(zhí)行時(shí)間,這一點(diǎn)在較大數(shù)據(jù)量的數(shù)據(jù)庫的操作中是非常重要的。在代碼上看,SQL語句和程序代碼語句的分離,可以提高程序代碼的 可讀性。 3. 存儲過程可以設(shè)置參數(shù),可以根據(jù)傳入?yún)?shù)的不同重復(fù)使用同一個(gè)存儲過程,從而高效的提高代碼的優(yōu)化率和可讀性。 4. 安全性高,可設(shè)定只有某此用戶才具有對指定存儲過程的使用權(quán)存儲過程的種類: A. 系統(tǒng)存儲過程:以sp_開頭,用來進(jìn)行系統(tǒng)的各項(xiàng)設(shè)定.取得信息.相關(guān)管理工作,如 sp_help就是取得指定對象的相關(guān)信息。 B. 擴(kuò)展存儲過程 以XP_開頭,用來調(diào)用操作系統(tǒng)提供的功能 C. 用戶自定義的存儲過程,這是我們所指的存儲過程常用格式 模版:Create procedure procedue_name [@parameter data_type][output] 解釋:output:表示此參數(shù)是可傳回的 with {recompile|encryption} recompile:表示每次執(zhí)行此存儲過程時(shí)都重新編譯一次;encryption:所創(chuàng)建的存儲過程的內(nèi)容會被加密。
但是最近我們項(xiàng)目組中有人寫了一個(gè)存儲過程,其計(jì)算時(shí)間為1個(gè)小時(shí)47分鐘,而有的時(shí)候運(yùn)行時(shí)間都超過了兩個(gè)小時(shí),同事描述說如果將存儲過程中的語句拿出來直接運(yùn)行也就10分鐘左右就運(yùn)行完畢,我沒當(dāng)回事,但是今天我自己寫的存儲過程也遇到了這個(gè)問題,在查找資料后原因終于找到了原因,原來是Parameter sniffing問題。 下面看我是如何將運(yùn)行一個(gè)小時(shí)以上的存儲過程優(yōu)化成在一分鐘之內(nèi)完成的: 原存儲過程 CREATE PROCEDURE [dbo].[pro_ImAnalysis_daily] @THEDATE VARCHAR(30) AS BEGIN IF @THEDATE IS NULL BEGIN SET @THEDATE=CONVERT(VARCHAR(30),GETDATE()-1,112); END
DELETE FROM RPT_IM_USERINFO_DAILY WHERE THEDATE=@THEDATE;
INSERT RPT_IM_USERINFO_DAILY (THEDATE,ALLUSER,NEWUSER) SELECT AA.THEDATE,ALLUSER,NEWUSER FROM ( ( SELECT THEDATE,COUNT(DISTINCT USERID) ALLUSER FROM FACT WHERE THEDATE=@THEDATE GROUP BY THEDATE ) AA LEFT JOIN (SELECT THEDATE,COUNT(DISTINCT USERID) NEWUSER FROM FACT T1 WHERE NOT EXISTS( SELECT 1 FROM FACT T2 WHERE T2.THEDATE<@THEDATE AND T1.USERID=T2.USERID) AND T1.THEDATE=@THEDATE GROUP BY THEDATE ) BB ON AA.THEDATE=BB.THEDATE); GO 每日執(zhí)行:exec pro_ImAnalysis_daily @thedate=null 經(jīng) 過查找資料,原因如下(由于源文是一篇英文,有些地方寫的我不是特別清楚,原文見http://groups.google.com/group /microsoft.public.sqlserver.server/msg/ad37d8aec76e2b8f?hl=en&lr=& amp;ie=UTF-8&oe=UTF-8): 在SQL Server中有一個(gè)叫做 “Parameter sniffing”的特性。SQL Server在存儲過程執(zhí)行之前都會制定一個(gè)執(zhí)行計(jì)劃。在上面的例子中,SQL在編譯的時(shí)候并不知道@thedate的值是多少,所以它在執(zhí)行執(zhí)行計(jì)劃的時(shí)候就要進(jìn)行大量的猜測。假設(shè)傳遞給@thedate的參數(shù)大部分都是非空字符串,而FACT表中有40%的thedate字段都是null,那么SQL Server就會選擇全表掃描而不是索引掃描來對參數(shù)@thedate制定執(zhí)行計(jì)劃。全表掃描是在參數(shù)為空或?yàn)?的時(shí)候最好的執(zhí)行計(jì)劃。但是全表掃描嚴(yán)重影響了性能。 假設(shè)你第一次使用了Exec pro_ImAnalysis_daily @thedate=’20080312’那么SQL Server就會使用20080312這個(gè)值作為下次參數(shù)@thedate的執(zhí)行計(jì)劃的參考值,而不會進(jìn)行全表掃描了,但是如果使用@thedate=null,則下次執(zhí)行計(jì)劃就要根據(jù)全表掃描進(jìn)行了。 有兩種方式能夠避免出現(xiàn)“Parameter sniffing”問題: (1)通過使用declare聲明的變量來代替參數(shù):使用set @variable=@thedate的方式,將出現(xiàn)@thedate的sql語句全部用@variable來代替。 (2) 將受影響的sql語句隱藏起來,比如: a) 將受影響的sql語句放到某個(gè)子存儲過程中,比如我們在@thedate設(shè)置成為今天后再調(diào)用一個(gè)字存儲過程將@thedate作為參數(shù)傳入就可以了。 b) 使用sp_executesql來執(zhí)行受影響的sql。執(zhí)行計(jì)劃不會被執(zhí)行,除非sp_executesql語句執(zhí)行完。 c) 使用動態(tài)sql(”EXEC(@sql)”來執(zhí)行受影響的sql。 采用(1)的方法改造例子中的存儲過程,如下: ALTER PROCEDURE [dbo].[pro_ImAnalysis_daily] @var_thedate VARCHAR(30)
AS BEGIN declare @THEDATE VARCHAR(30) IF @var_thedate IS NULL BEGIN SET @var_thedate=CONVERT(VARCHAR(30),GETDATE()-1,112); END
SET @THEDATE=@var_thedate; DELETE FROM RPT_IM_USERINFO_DAILY WHERE THEDATE=@THEDATE;
INSERT RPT_IM_USERINFO_DAILY (THEDATE,ALLUSER,NEWUSER) SELECT AA.THEDATE,ALLUSER,NEWUSER FROM ( ( SELECT THEDATE,COUNT(DISTINCT USERID) ALLUSER FROM FACT WHERE THEDATE=@THEDATE GROUP BY THEDATE ) AA LEFT JOIN (SELECT THEDATE,COUNT(DISTINCT USERID) NEWUSER FROM FACT T1 WHERE NOT EXISTS( SELECT 1 FROM FACT T2 WHERE T2.THEDATE<@THEDATE AND T1.USERID=T2.USERID) AND T1.THEDATE=@THEDATE GROUP BY THEDATE ) BB ON AA.THEDATE=BB.THEDATE); GO
測試執(zhí)行速度為10分鐘,我又檢查了一下這個(gè)SQL,發(fā)現(xiàn)這個(gè)SQL有問題,這個(gè)SQL使用了not exists,在一個(gè)大表里面使用not exists是不太明智的,所以,我又對這個(gè)sql進(jìn)行了改進(jìn),改成如下: ALTER PROCEDURE [dbo].[pro_ImAnalysis_daily] @var_thedate VARCHAR(30)
AS BEGIN declare @THEDATE VARCHAR(30) IF @var_thedate IS NULL BEGIN SET @var_thedate=CONVERT(VARCHAR(30),GETDATE()-1,112); END
SET @THEDATE=@var_thedate; DELETE FROM RPT_IM_USERINFO_DAILY WHERE THEDATE=@THEDATE;
INSERT RPT_IM_USERINFO_DAILY(THEDATE,ALLUSER,NEWUSER) select @thedate as thedate, count(distinct case when today>0 then userid else null end) as alluser, count(distinct case when dates=0 then userid else null end) as newuser from ( select userid, count(CASE WHEN thedate>=@thedate then null else thedate end) as dates, count(case when thedate=@thedate then thedate else null end) as today from FACT group by userid )as fact GO 測試結(jié)果為30ms以下。 該文章在 2024/6/21 17:12:49 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |