SQL Server 优化存储过程的方法有哪些
优化存储过程有很多种方法，下面介绍最常使用的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
======================分割线=======================
『自己的一些调优经验』
1.少使用游标是个很好的建议，为此，我自己也碰到过一些事故，是游标所造成的，由于，游标是逐行逐行操作的，当记录较多时，时常会碰到超时的情况。
2.多表join做查询时，查询的字段尽可能不要使用case when then else end的语法，或使用网民函数，例如：
select(case when fType=1 then'是' else'否' end) as fTypeName, dbo.F_GetFullName(fID) as fFullName from Table1 inner join Table2……
当两个表的数据量非常大时，你可在查询分析器中明显感觉到：直接查询fType和fID与查询上面两个字段的速度，很可能找到用了一个case when then就导致超时。
针对这种情况，可以分两种做法：
第一，把一些简单的转换可以放在程序中完成。
第二，如果要通过ID查询全名或全称，类似的，可以创建好视图，直接查视图，或，先把所有的fFullName查出来放到临时表中，直接join临时表（如果这一个数据不是很多的话），获得fFullName。
3.少使用一些嵌套的查询，用临时表缓存中间数据，例如：
select* from Table1
inner join(
select count(1) as count, Table2.ID2 from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
) as t1 on t1.ID1= Table1.ID1
我曾经碰到这样情况，上面的语句是那种情况的简化版本，把其他不影响结果的表格都去掉了，发现一个奇怪的现象：嵌套查询的结果集并不大，大约就200多行，Table1有6w条记录，结果，这一个查询语句超时，查询分析器中执行2分钟也得不到结果。
后来，这样一改，就Ok了，3秒出结果：
select count(1) as count, Table2.ID2 into#temp from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
select* from Table1
inner join#temp as t1 on t1.ID1= Table1.ID1
这样一改，效率提高了几十倍，猜想：可能是嵌套的查询是动态的，每一行的join可能都需要先执行嵌套的查询，从此导致效率极差。
所以，如果查询足够复杂，join多个表，需要连接多个通过group by求和、求平均数等运算计算出来的中间数据，那么，不妨多使用临时表缓存中间数据。
4.还有些是必须遵守的一些默认规则，例如：
先过滤后连接。
查询的字段最要不要使用“*”，指定要用的字段，减少网络流量。
『总结』
对于性能的追求是没有极限的，做到你所能做到的，这是一个很好的习惯。
有些业务逻辑放在存储过程中处理比较方便，而有些业务逻辑交给程序来处理，同样会提高系统整体的效率，看实际情况而定。
总之，尽最大可能减少这些容易引发性能问题的隐患，系统就会跑得更稳定更具有效率，一切从小细节做起。
优化SQL有什么方法
（1）SELECT子句中避免用‘*’：
Oracle在解析的过程中,会将‘*’依次转换成所有的列名,这一个工作是通过查询数据字典完成的,这就意味着将耗费更加多的时间。
（2）尽可能多使用COMMIT：
只要有大可能，在程序中尽可能多使用COMMIT,这样程序的性能得到提高,需求也会因为COMMIT所释放的资源而减少，COMMIT所释放的资源:
a.回滚段上用于恢复数据的信息。
b.被程序语句获得的锁。
c.redo log buffer中的空间。
（3）用Where子句替换HAVING子句：
避免用HAVING子句, HAVING只会在检索出所有记录之后才对结果集进行过滤。这一个处理需要排序,总计等操作.
如果可以通过WHERE子句限制记录的数目，那就能减少这方面的开销。(非oracle中)on、where、having这三个都能加条件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。
在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where可使用rushmore技术，而having就不能，在速度上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这一个字段的值是不确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而having就是在计算后才起作用的，因此，两者的结果会不一样。
在多表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完之后再由
having进行过滤。由此可以看见，要想过滤条件起到正确的作用，首先需要明白这一个条
件应在什么时候起作用，然后再决定放在那里。
（4）用EXISTS替代IN、用NOTEXISTS替代NOT IN：
在许多基于基础表的查询中,为了满足一个条件,往往需要对另外一个表进行联接。
在这种场合下,使用EXISTS(或NOTEXISTS)通常将提高查询的效率。在子查询中,NOT IN子句将执行一个内部的排序和合并。无论在哪种情况下
,NOTIN都是最低效的(因为它对子查询中的表执行了一个全表遍历)。为了避免用NOT IN,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS。
例子：
（高效）
SELECT* FROM EMP(基础表)WHERE EMPNO> 0 AND EXISTS(SELECT‘X' FROM DEPT WHEREDEPT.DEPTNO= EMP.DEPTNO AND LOC=‘MELB')
(低效)
SELECT* FROM EMP(基础表) WHERE EMPNO> 0 ANDDEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC=‘MELB')
（5）用索引提高效率：
索引是表的一个概念部分，用来提高检索数据的效率，
Oracle使用了一个复杂的自平衡B-tree结构。通常,通过索引查询数据比全表扫描要快。当Oracle找出执行查询和Update语句的最佳路径时, Oracle优化器将使用索引。同样在联结多个表时使用索引也可提高效率。另外一个使用索引的好处是,它提供了主键(primary key)的唯一性验证。
那些LONG或LONG RAW数据类型,你可以索引几乎所有的列。通常,在大型表中使用索引特别有效.当然,你也会发现,在扫描小表时，使用索引同样能提高效率。虽然使用索引能得到查询效率的提高,但是我们也必须留意到它的代价。
索引需要空间来存储，也需要定期维护,每当有记录在表中增减或索引列被撰改时,索引本身也会被撰改。这就意味着每条记录的INSERT, DELETE, UPDATE将为此多付出4, 5次的磁盘I/O。因为索引需要额外的存储空间和处理,那些不必要的索引反而会使查询反应时间变慢。定期的重构索引是很有必要的：
ALTERINDEX<INDEXNAME> REBUILD<TABLESPACENAME>（18）用EXISTS替换DISTINCT：当提交一个包含一对多表信息(例如部门表和雇员表)的查询时,避免在SELECT子句中使用DISTINCT。一般可考虑用EXIST替换, EXISTS使查询更为迅速,因为RDBMS核心模块将在子查询的条件一旦满足后,立刻返回结果。
例子：
(低效):
SELECTDISTINCT DEPT_NO,DEPT_NAME FROM DEPT D, EMP E WHERE D.DEPT_NO= E.DEPT_NO
(高效):
SELECTDEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS( SELECT‘X' FROM EMP E WHEREE.DEPT_NO= D.DEPT_NO);
