SQL Server中存储过程比直接运行SQL语句慢的缘由

原文: SQL Server中存储过程比直接运行SQL语句慢的缘由

    在不少的资料中都描述说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=&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如下。