SQL Server中存儲過程 比 直接運行SQL語句慢的緣由

問題是存儲過程的Parameter sniffing

 

 

在不少的資料中都描述說SQLSERVER的存儲過程較普通的SQL語句有如下優勢：

1. 存儲過程只在創造時進行編譯便可，之後每次執行存儲過程都不需再從新編譯，而咱們一般使用的SQL語句每執行一次就編譯一次,因此使用存儲過程可提升數據庫執行速度。

2. 常常會遇到複雜的業務邏輯和對數據庫的操做，這個時候就會用SP來封裝數據庫操做。當對數據庫進行復雜操做時(如對多個表進行 Update,Insert,Query,Delete時），可將此複雜操做用存儲過程封裝起來與數據庫提供的事務處理結合一塊兒使用。能夠極大的提升數據 庫的使用效率，減小程序的執行時間，這一點在較大數據量的數據庫的操做中是很是重要的。在代碼上看，SQL語句和程序代碼語句的分離，能夠提升程序代碼的 可讀性。

3. 存儲過程能夠設置參數，能夠根據傳入參數的不一樣重複使用同一個存儲過程，從而高效的提升代碼的優化率和可讀性。

4. 安全性高,可設定只有某此用戶才具備對指定存儲過程的使用權存儲過程的種類：

A. 系統存儲過程：以sp_開頭,用來進行系統的各項設定.取得信息.相關管理工做,如 sp_help就是取得指定對象的相關信息。

B. 擴展存儲過程 以XP_開頭,用來調用操做系統提供的功能
exec master..xp_cmdshell 'ping 10.8.16.1'

C. 用戶自定義的存儲過程,這是咱們所指的存儲過程經常使用格式

模版：Create procedure procedue_name [@parameter data_type][output]
    [with]{recompile|encryption} as sql_statement

解釋：output：表示此參數是可傳回的

with {recompile|encryption} recompile:表示每次執行此存儲過程時都從新編譯一次;encryption:所建立的存儲過程的內容會被加密。

可是最近咱們項目組中有人寫了一個存儲過程,其計算時間爲1個小時47分鐘,而有的時候運行時間都超過了兩個小時,同事描述說若是將存儲過程當中的語句拿出來直接運行也就10分鐘左右就運行完畢，我沒當回事，可是今天我本身寫的存儲過程也遇到了這個問題，在查找資料後緣由終於找到了緣由，原來是Parameter sniffing問題。

下面看我是如何將運行一個小時以上的存儲過程優化成在一分鐘以內完成的：

原存儲過程

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

每日執行:exec pro_ImAnalysis_daily @thedate=null
耗時：1小時47分~2小時13分

經 過查找資料，緣由以下(因爲源文是一篇英文，有些地方寫的我不是特別清楚，原文見http://groups.google.com/group /microsoft.public.sqlserver.server/msg/ad37d8aec76e2b8f?hl=en&lr=& amp;ie=UTF-8&oe=UTF-8)：

在SQL Server中有一個叫作 「Parameter sniffing」的特性。SQL Server在存儲過程執行以前都會制定一個執行計劃。在上面的例子中，SQL在編譯的時候並不知道@thedate的值是多少，因此它在執行執行計劃的時候就要進行大量的猜想。假設傳遞給@thedate的參數大部分都是非空字符串，而FACT表中有40%的thedate字段都是null，那麼SQL Server就會選擇全表掃描而不是索引掃描來對參數@thedate制定執行計劃。全表掃描是在參數爲空或爲0的時候最好的執行計劃。可是全表掃描嚴重影響了性能。

假設你第一次使用了Exec pro_ImAnalysis_daily @thedate=’20080312’那麼SQL Server就會使用20080312這個值做爲下次參數@thedate的執行計劃的參考值，而不會進行全表掃描了，可是若是使用@thedate=null,則下次執行計劃就要根據全表掃描進行了。

解決方法:

有兩種方式可以避免出現「Parameter sniffing」問題：

(1)經過使用declare聲明的變量來代替參數：使用set @variable=@thedate的方式，將出現@thedate的sql語句所有用@variable來代替。

(2) 將受影響的sql語句隱藏起來，好比：

a) 將受影響的sql語句放到某個子存儲過程當中，好比咱們在@thedate設置成爲今天后再調用一個字存儲過程將@thedate做爲參數傳入就能夠了。

b) 使用sp_executesql來執行受影響的sql。執行計劃不會被執行，除非sp_executesql語句執行完。

c) 使用動態sql（」EXEC(@sql)」來執行受影響的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

測試執行速度爲10分鐘，我又檢查了一下這個SQL，發現這個SQL有問題，這個SQL使用了not exists，在一個大表裏面使用not exists是不太明智的，因此，我又對這個sql進行了改進，改爲以下：

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

測試結果爲30ms如下。

 

引用: http://www.oecp.cn/hi/shua0376/blog/2062

 

資料: http://www.cnblogs.com/lyhabc/articles/3222179.html