SQL Server数据库性能优化（一）之 优化SQL 语句

最近工做上基本没什么需求（好吧 不是最近是很久了，因此随便看看基础的东西来填补本身的空白）

原文出自：http://www.blogjava.net/allen-zhe/archive/2010/07/23/326927.html   转载请保留

数据库优化主要能够从如下几个方面入手

（1）架构级别，表结构设计：如良好的系统和数据库设计

（2）代码语句级别：优质的SQL编写

（3）索引设计：合适的数据表索引设计

（4）硬件因素：网络性能、服务器的性能、操做系统的性能，甚至网卡、交换机等

 

这里主要讨论最容易修改优化的 SQL 语句

准则1：1. 按需索取字段，跟“SELECT *”说拜拜

 字段的提取必定要按照“用多少提多少”的原则，避免使用“SELECT *”这样的操做。

作了这样一个实验，表tblA有1000万数据：

select top 10000 c1, c2, c3, c4 from tblA order by c1 desc  --用时：4673毫秒
select top 10000 c1, c2, c3 from tblA order by c1 desc --用时：1376毫秒
select top 10000 c1, c2 from tblA order by c1 desc --用时：80毫秒

由此看来，咱们每少提取一个字段，数据的提取速度就会有相应的提高。但提高的速度还要看您舍弃的字段的大小来判断。
另外，关于“SELECT *“的问题，能够参考这篇文章：
http://www.cnblogs.com:80/goodspeed/archive/2007/07/20/index_coverage.html  //此文章评论争议很大 因此此处不推荐阅读

 

准则2：2. 字段名和表名要写规范，注意大小写
这一点要多注意，若是大小写写错的话，虽然SQL仍然能正常执行，但数据库系统会花必定的开销和时间先要把您写的规范成正确的，而后再执行SQL。写对的话，这个时间就省了。
正常的：    select top 10 dteTransaction, txtSystem_id from tblTransactionSystem
不当心的：select top 10 dtetransaction, txtsystem_id from tbltransactionsystem

 

准则3：3. 适当使用过渡表
把表的一个子集进行排序并建立临时表，有时能加速查询。它有助于避免多重排序操做，并且在其余方面还能简化优化器的工做。例如：

 

SELECT cust.name，rcvbles.balance，……other   columns     
FROM cust，rcvbles     
WHERE cust.customer_id = rcvlbes.customer_id     
AND rcvblls.balance>0     
AND cust.postcode>“98000”     
ORDER BY cust.name

  若是这个查询要被执行屡次而不止一次，能够把全部未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：    

 

SELECT cust.name，rcvbles.balance，……other   columns     
INTO temp_cust_with_balance     
FROM cust，rcvbles     
WHERE cust.customer_id = rcvlbes.customer_id     
AND rcvblls.balance>0     
ORDER BY cust.name

 

  而后如下面的方式在临时表中查询：     

 

SELECT cl,c2 FROM temp_cust_with_balance WHERE  postcode>“98000”

 

临时表中的行要比主表中的行少，并且物理顺序就是所要求的顺序，减小了磁盘I/O，因此查询工做量能够获得大幅减小。注意：过渡临时表建立后不会反映主表的修改。在主表中数据频繁修改的状况下，注意不要丢失数据。

准则4. 别在where条件中作函数计算
这样作的后果是将在每一个行上进行运算，这将致使该列的索引失效而触发全表扫描。以下SQL：

select * from users where YEAR(dteCreated) < 2007

能够改为

select * from users where dteCreated <‘2007-01-01’

这样会使用针对dteCreated的索引，提升查询效率。

准则5. IN（NOT IN）操做符与EXISTS（NOT EXISTS）操做符
有时候会将一列和一系列值相比较。最简单的办法就是在where子句中使用子查询。在where子句中可使用两种方式的子查询。以下：
第一种方式使用IN操做符：

select a.id from tblA a where a.id in (select b.id from tblB b)

 

第二种方式使用EXIST操做符：

select a.id from tblA a where exists (select 1 from tblB b where b.id = a.id)

 

用IN写出来的SQL的优势是比较容易写及清晰易懂，这比较适合现代软件开发的风格。可是用IN的SQL性能老是比较低的，而第二种格式要远比第一种格式的效率高。从SQL执行的步骤来分析用IN的SQL与不用IN的SQL有如下区别：
SQL试图将其转换成多个表的链接，若是转换不成功则先执行IN里面的子查询，再查询外层的表记录，若是转换成功则直接采用多个表的链接方式查询。因而可知用IN的SQL至少多了一个转换的过程。通常的SQL均可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。
第二种格式中，子查询以’select 1’开始。运用EXISTS子句无论子查询从表中抽取什么数据它只查看where子句。这样优化器就没必要遍历整个表而仅根据索引就可完成工做（这里假定在where语句中使用的列存在索引）。相对于IN子句来讲，EXISTS使用相连子查询，构造起来要比IN子查询困难一些。
经过使用EXIST，数据库系统会首先检查主查询，而后运行子查询直到它找到第一个匹配项，这就节省了时间。数据库系统在执行IN子查询时，首先执行子查询，并将得到的结果列表存放在一个加了索引的临时表中。在执行子查询以前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中之后再执行主查询。这也就是使用EXISTS比使用IN一般查询速度快的缘由。
同时应尽量使用NOT EXISTS来代替NOT IN，尽管两者都使用了NOT（不能使用索引而下降速度），NOT EXISTS要比NOT IN查询效率更高。

准则6. IS NULL 或 IS NOT NULL操做（判断字段是否为空）
不能用null做索引，任何包含null值的列都将不会被包含在索引中，由于B树索引是不索引空值的。即便索引有多列这样的状况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说若是某列存在空值，即便对该列建索引也不会提升性能。
任何在where子句中使用is null或is not null的语句优化器是不容许使用索引的。
推荐方案：用其它相同功能的操做运算代替，如a is not null 改成 a>0 或a>’等。另外还设置字段不容许为空，而用一个缺省值代替空值，如一个datetime字段，能够将默认时间设为“1900-01-01”。

准则7. > 及 < 操做符（大于或小于操做符）
       大于或小于操做符通常状况下是不用调整的，由于它有索引就会采用索引查找，但有的状况下能够对它进行优化，如一个表有100万记录，一个数值型字段A，30 万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，由于 A>2时sql会先找出为2的记录索引再进行比较，而A>=3时sql则直接找到=3的记录索引。可结合非汇集索引一块儿考虑。

准则8. LIKE操做符
LIKE 操做符能够应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，可是若是用得很差则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。由于索引的摆放是依据字段值升序或降序排列，like'%*'这种用法，不能利用有序的数据结构，利用二分法查找数据。一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描，若是改为YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能确定大大提升。

准则9. 查询条件中的适当与不适当
查询参数能够包含一下操做：=、<、>、>=、<=、BETWEEN、部分like。其中，like当这样使用时会用到索引：like '*%',但like'%*'就用不到索引。
不适当的查询参数有：NOT 、!= 、<>、 !>、 !< 、NOT EXISTS、 NOT IN 、NOT LIKE等，还有一些不当的用法，例如：对数据进行计算，负向查询、等号左边使用函数、使用OR。上述语法都用不上索引，下降程序的效率。

准则10. 慎用DELETE

通常在存储过程当中或多或少都会实现一些删除数据的逻辑。对小数量的表来讲，问题却是不大。但对于大数据量的表来讲，采用delete删除数据会对储存过程的性能产生必定的影响。由于delete采用的是全表逐条扫描的方式进行，是一种事务性操做，会计入SQL Server的事务日志中。不但增长了运行时间，同时也频繁写入LOG文件，致使LOG文件过大，过度消耗磁盘空间。因此，能够用truncate操做代替delete，truncate并不会计入事务日志中，同时也是不带条件的删除，执行速度很快。又或者直接drop掉表从新建立，有时都会比delete来得快。

 

 

PS: 第10点引出的两种清空SQL Server日志文件的方法

一种方法：清空日志。

1．打开查询分析器，输入命令DUMP TRANSACTION 数据库名 WITH NO_LOG

2.再打开企业管理器--右键你要压缩的数据库--全部任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个容许收缩到的最小M数,直接输入这个数,肯定就能够了。

另外一种方法有必定的风险性，由于SQL SERVER的日志文件不是即时写入数据库主文件的，如处理不当，会形成数据的损失。

1: 删除LOG

分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库

2：删除LOG文件

附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库

此法生成新的LOG，大小只有500多K。

下边的内容来自 <程序员SQL金典>

准则11：尽可能将多条SQL语句压缩到一句SQL中

每次执行SQL的时候都要创建网络链接，进行权限校验，进行SQL语句的查询优化/发送执行结果，这个过程是很是耗时的，所以尽可能避免过多的执行SQL语句

//这一条  本人以为有异议  由于这样会致使sql语句非原子性的存在  耦合性更高 若是业务发生变更的话 须要从新修改SQL语句这是很没必要要的   因此结合的时候要注意

准则12：使用表的别名

当在SQL 语句中链接多个表时，最好使用表的别名，并把别名前缀置于每个列名上，这样能够减小解析的时间，也能够减小因为列名的歧义产生的错误，好比 两张表中的 列名 很接近。

准则13：用表链接代替Exists

一般来讲表链接的方式比Exists 更有效率，所以若是可能的话尽可能使用表链接替换Exists。 

//这一条本人有异议，由于表链接会过长的占用某张表，若是一张表须要快速的操做，则在其余地方出现链接使用这张表时，则会使总体的执行效率变慢，尽管链接的表可能不受影响。 这也是为何不少大型系统不容许多张表链接操做的

准则14：避免在索引列上使用计算

在WHERE 字句中，若是索引列是计算或者函数的部分，DBMS的优化器将不会使用索引而进行全表扫描。

准则15:避免隐式类型的转换形成的全表扫描

在大部分数据库的隐式转换类型中数值类型的优先级高于字符串类型，所以DBMS会对比较时的不一样类型作隐式转换，有时会将字符串类型变为数值类型致使索引失效而进行全表扫描 

准则16：防止检索范围过宽

若是DBMS优化器认为检索范围过宽，那么他将放弃索引查找而使用全表扫描，下面是形成检索范围过宽的状况：

1使用 IS not Null 或者不等于判断，可能形成优化器假设匹配的记录数量太大。

2使用LIKE的时候 a%会使用索引而 a%b %c则会使用全表扫描，所以a%b %c不能有效的评估匹配的数量

准则17：必要时采用Union ALL 替换Union

二者区别是 Union ALL 会查找全部结果  而Union 会合并两张表的重复记录

假若两张表的数据所有惟一时，Union 仍然会试图在结果集中进行合并