sql优化常用的几种方法，sql优化常用的几种方法有哪些

sql优化常用的15种方法

SQL优化常用的15种方法包括：

选择最有利的字段做索引：索引是SQL优化的关键，选择经常作为查询条件的字段建立索引，可以大大提高查询速度。避免在索引列上使用计算或函数：这会导致索引失效，降低查询效率。使用连接（JOIN）来代替子查询：在某些情况下，连接比子查询更高效。优化LIKE语句：尽量避免使用前置通配符，这会导致全表扫描。使用LIMIT分页：对于大量数据的查询，使用LIMIT进行分页可以提高性能。*避免SELECT语句：只选择需要的字段，减少数据传输量。减少查询的嵌套层次：多层嵌套查询会增加数据库的负担，尽量简化查询结构。使用EXPLAIN分析查询：EXPLAIN可以帮助你了解查询的执行计划，从而找出性能瓶颈。优化数据库设计：合理的数据库设计是SQL优化的基础，包括表结构、索引、分区等。使用数据库缓存：利用数据库的缓存机制，可以减少对磁盘的访问，提高查询速度。避免大事务：大事务会占用更多的系统资源，尽量将大事务拆分成多个小事务。使用预编译语句：预编译语句可以减少SQL语句的解析时间，提高执行效率。调整数据库参数：根据硬件环境和业务需求，合理调整数据库的参数设置。定期清理无用数据：定期清理过期或无效的数据，可以减小数据库的大小，提高查询性能。硬件升级：如果数据库性能达到瓶颈，考虑升级硬件设备，如增加内存、使用更快的存储等。

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.还有一些是必须遵守的一些默认规则，比如：

先过滤后连接。

查询的字段最要不要用“*”，指定需要用的字段，减少网络流量。

『总结』

对于性能的追求是没有极限的，做到你所能做到的，这是一个很好的习惯。

有些业务逻辑放在存储过程中处理比较方便，而有些业务逻辑交给程序来处理，同样会提升系统整体的效率，看实际情况而定。

总之，尽可能减少这些容易引发性能问题的隐患，系统就会跑得更稳定更有效率，一切从小细节做起。