日期:2014-05-17  浏览次数:20502 次

大家有什么好的存储过程优化方法吗?
公司里有个存储过程,写了几千行代码。其中用了10几张临时表。很多临时变量。
我想问下大家,平时写存储过程有没有什么好的优化方法,经验呢?
希望大家说的方法越多越好。


------解决方案--------------------
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/songguozhi/archive/2010/09/14/5883191.aspx

SQL code
优化存储过程有很多种方法,下面介绍最常用的7种。

1.使用SET NOCOUNT ON选项

我们使用SELECT语句时,除了返回对应的结果集外,还会返回相应的影响行数。使用SET NOCOUNT ON后,除了数据集就不会返回额外的信息了,减小网络流量。

2.使用确定的Schema

在使用表,存储过程,函数等等时,最好加上确定的Schema。这样可以使SQL Server直接找到对应目标,避免去计划缓存中搜索。而且搜索会导致编译锁定,最终影响性能。比如select * from dbo.TestTable比select * from TestTable要好。from TestTable会在当前Schema下搜索,如果没有,再去dbo下面搜索,影响性能。而且如果你的表是csdn.TestTable的话,那么select * from TestTable会直接报找不到表的错误。所以写上具体的Schema也是一个好习惯。

3.自定义存储过程不要以sp_开头

因为以sp_开头的存储过程默认为系统存储过程,所以首先会去master库中找,然后在当前数据库找。建议使用USP_或者其他标识开头。

4.使用sp_executesql替代exec

原因在Inside Microsoft SQL Server 2005 T-SQL Programming书中的第四章Dynamic SQL里面有具体描述。这里只是简单说明一下:sp_executesql可以使用参数化,从而可以重用执行计划。exec就是纯拼SQL语句。

5.少使用游标

可以参考Inside Microsoft SQL Server 2005 T-SQL Programming书中的第三章Cursors里面有具体描述。总体来说,SQL是个集合语言,对于集合运算具有较高的性能,而Cursors是过程运算。比如对一个100万行的数据进行查询,游标需要读表100万次,而不使用游标只需要少量几次读取。

6.事务越短越好

SQL Server支持并发操作。如果事务过多过长,或是隔离级别过高,都会造成并发操作的阻塞,死锁。此时现象是查询极慢,同时cup占用率极低。

7.使用try-catch来处理错误异常

SQL Server 2005及以上版本提供对try-catch的支持,语法为:

begin try  
      ----your code 
end try 
begin catch 
       --error dispose 
end catch

一般情况可以将try-catch同事务结合在一起使用。

begin try 
    begin tran 
        --select 
        --update 
        --delete 
        --………… 
    commit 
end try 
begin catch 
    --if error 
    rollback 
end catch