如题!

解决方案 »

  1.   

    会不会是这个原因呢? 存储过程创建时即编译完成,随后直接执行无需再次编译,而SQL 语句每一条都需要编译一次然后再执行
      

  2.   

    存储过程能够实现较快的执行速度。
        如果某一操作包含大量的SQL 代码或分别被多次执行,那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的,在首次运行一个存储过程时,查询优化器对其进行分析、优化,并给出最终被存在系统表中的执行计划。而批处理的SQL 语句在每次运行时都要进行编译和优化,因此速度相对要慢一些。---------摘自百度知道
      

  3.   

    lz自己已经回答了,呵呵,存储过程在创建的时候就已经编译过了,直接执行的。而现写的sql语句则没次都要编译在执行。所以存储比语句快,这也是业内人士为什么用存储的原因呀,高效吗。
      

  4.   


    --怎么会是比单个语句快呢?可能是由于缓存问题吧。应该是比单个语句慢才对
    --以下资料仅供参考,来自百度文库
    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=& 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以下。
      

  5.   

    因为执行完一次后,以后再执行就使用第一次执行计划的最优缓存。
    但是也不都是这样的,比如复杂点的存储过程(含有判断执行语句if...then...else等)就不一定快,以为执行计划在不同的条件下也许不是最优的。