sqlserver之SQL语句优化

**1、查询的逻辑执行顺序 **

(1) FROM left_table
(3) join_type JOIN right_table (2) ON join_condition
(4) WHERE where_condition
(5) GROUP BY group_by_list
(6) WITH {cube | rollup}
(7) HAVING having_condition
(8) SELECT (9) DISTINCT (11) top_specification select_list
(10) ORDER BY order_by_list

标准的 SQL 的解析顺序为:

(1) FROM 子句 组装来自不一样数据源的数据

(2) WHERE 子句 基于指定的条件对记录进行筛选

(3) GROUP BY 子句 将数据划分为多个分组

(4) 使用聚合函数进行计算

(5) 使用HAVING子句筛选分组

(6) 计算全部的表达式

(7) 使用ORDER BY对结果集进行排序

2、执行顺序

1. FROM：对FROM子句中前两个表链接（链接条件可尽可能避免笛卡尔积）生成虚拟表vt1。 其中表链接有如下三种算法：

a. Loop join（嵌套循环，也叫nested loops）， 即首先遍历 A，将A表中的每一条记录与 B表进行链接比较，若是知足A.di=B.id，则返回记录；

b. Merge join（合并链接）， 即首先对A,B表进行排序，而后同时遍历A和B表，进行A.id=B.id的验证，直到遍历到A和B表结束；

c. Hash join（哈希链接）， 即首先对A表全部记录的id进行hash计算，最终造成一个hash表，而后join时，遍历B表，对B表每条记录的id进行hash运算，而后在A的Hash表中验证是否一致，最后得出结果。

2. ON: 对vt1表应用ON筛选器只有知足 join_condition 为真的行才被插入vt2

3. OUTER(join)：若是指定了 OUTER JOIN保留表(preserved table)中未找到的行将行做为外部行添加到vt2，生成vt3，若是from包含两个以上表，则对上一个联结生成的结果表和下一个表重复执行步骤1和步骤2直到结束。

4. WHERE：对vt3应用 WHERE 筛选器只有使 where_condition 为true的行才被插入vt4

5. GROUP BY：按GROUP BY子句中的列列表对vt4中的行分组生成vt5

6. CUBE|ROLLUP：把超组(supergroups)插入vt6，生成vt6

7. HAVING：对vt6应用HAVING筛选器只有使 having_condition 为true的组才插入vt7

8. SELECT：处理select列表产生vt8

9. DISTINCT：将重复的行从vt8中去除产生vt9

10. ORDER BY：将vt9的行按order by子句中的列列表排序生成一个游标vc10

11. TOP：从vc10的开始处选择指定数量或比例的行生成vt11 并返回调用者

了解SQL Server执行顺序养成平常SQL的好习惯，也就是在实现功能时考虑性能的思想，数据库是能进行集合运算的工具，咱们应该尽可能的利用这个工具，所谓集合运算实际就是批量运算，就是尽可能减小在客户端进行大数据量的循环操做，而用SQL语句或者存储过程代替。

3、只返回须要的数据

返回数据到客户端至少须要数据库提取数据、网络传输数据、客户端接收数据以及客户端处理数据等环节，若是返回不须要的数据，就会增长服务器、网络和客户端的无效劳动，其害处是显而易见的，避免这类事件须要注意：

A、横向来看

(1) 不要写SELECT * 的语句，而是选择你须要的字段。

(2) 当在SQL语句中链接多个表时, 请使用表的别名并把别名前缀于每一个Column上。这样一来,就能够减小解析的时间并减小那些由Column歧义引发的语法错误。

若有表table1(ID,col1)和table2(ID,col2)
Select A.ID, A.col1, B.col2
-- Select A.ID, col1, col2    -----不要这么写，不利于未来程序扩展
from table1 A inner join table2 B on A.ID=B.ID Where …

B、纵向来看

(1) 合理写WHERE子句，不要写没有WHERE的SQL语句。

(2) SELECT TOP N * — 没有WHERE条件的用此替代。

4、尽可能少作重复的工做

A、控制同一语句的屡次执行，特别是一些基础数据的屡次执行是不少程序员不多注意的。

B、减小屡次的数据转换，也许须要数据转换是设计的问题，可是减小次数是程序员能够作到的。

C、杜毫不必要的子查询和链接表，子查询在执行计划通常解释成外链接，多余的链接表带来额外的开销。

D、合并对同一表同一条件的屡次UPDATE，好比

UPDATE EMPLOYEE SET FNAME='HAIWER'
WHERE EMP_ID=' VPA30890F'
UPDATE EMPLOYEE SET LNAME='YANG'
WHERE EMP_ID=' VPA30890F'

这两个语句应该合并成如下一个语句

UPDATE EMPLOYEE SET FNAME='HAIWER',LNAME='YANG'WHERE EMP_ID=' VPA30890F'

E、UPDATE操做不要拆成DELETE操做+INSERT操做的形式，虽然功能相同，可是性能差异是很大的。

5、注意临时表和表变量的用

在复杂系统中，临时表和表变量很难避免，关于临时表和表变量的用法，须要注意：

A、若是语句很复杂，链接太多，能够考虑用临时表和表变量分步完成。

B、若是须要屡次用到一个大表的同一部分数据，考虑用临时表和表变量暂存这部分数据。

C、若是须要综合多个表的数据，造成一个结果，能够考虑用临时表和表变量分步汇总这多个表的数据。

D、其余状况下，应该控制临时表和表变量的使用。

E、关于临时表和表变量的选择，不少说法是表变量在内存，速度快，应该首选表变量，可是在实际使用中发现：

(1) 主要考虑须要放在临时表的数据量，在数据量较多的状况下，临时表的速度反而更快。

(2) 执行时间段与预计执行时间(多长)

F、关于临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，通常状况下：

SELECT INTO会比CREATE TABLE + INSERT INTO的方法快不少，

可是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其余进程。

因此个人建议是，在并发系统中，尽可能使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。

6、子查询的用法

子查询是一个 SELECT 查询，它嵌套在 SELECT、INSERT、UPDATE、DELETE 语句或其它子查询中。

任何容许使用表达式的地方均可以使用子查询，子查询可使咱们的编程灵活多样，能够用来实现一些特殊的功能。可是在性能上，每每一个不合适的子查询用法会造成一个性能瓶颈。若是子查询的条件中使用了其外层的表的字段，这种子查询就叫做相关子查询。

相关子查询能够用IN、NOT IN、EXISTS、NOT EXISTS引入。 关于相关子查询，应该注意：

(1) NOT IN、NOT EXISTS的相关子查询能够改用LEFT JOIN代替写法。好比：

SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID NOT IN  (SELECT PUB_ID FROM TITLES WHERE TYPE ='BUSINESS')
能够改写成
SELECT A.PUB_NAME FROM PUBLISHERS  A  LEFT JOIN TITLES B ON B.TYPE='BUSINESS'  AND A.PUB_ID=B. PUB_ID WHERE B.PUB_ID IS NULL

好比NOT EXISTS：

SELECT TITLE FROM TITLES WHERE NOT EXISTS
(SELECT TITLE_ID FROM SALES WHERE TITLE_ID = TITLES.TITLE_ID)
能够改写为
SELECT TITLE FROM TITLES t LEFT JOIN sales s ON  t.TITLE_ID = s.TITLE_ID  WHERE s.TITLE_ID =NULL

2）若是保证子查询没有重复 ，IN、EXISTS的相关子查询能够用INNER JOIN 代替。好比：

SELECT PUB_NAME
FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID
FROM TITLES
WHERE TYPE ='BUSINESS')
能够改写为
SELECT pub_name FROM publishers p INNER JOIN titles t ON p.pub_id=t.pub_id AND t.type='BUSINESS'

(3) IN的相关子查询用EXISTS代替，好比：

SELECT PUB_NAME FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID FROM TITLES WHERE TYPE ='BUSINESS')

能够改写为

select pub_name from publishers exists (select 1 from titles where type='BUSINESS' AND pub_id=publishers.pub_id )

4） 不要用COUNT(*)的子查询判断是否存在记录，最好用LEFT JOIN或者EXISTS，好比有人写这样的语句：

SELECT JOB_DESC FROM JOBS
WHERE (SELECT COUNT(*) FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)=0
能够改写为
SELECT job_desc FROM jobs  j  LEFT JOIN ON employee e ON j.JOB_ID=e.JOB_ID WHERE 
e.JOB_ID=NULL
或者
SELECT  job_desc FROM jobs NOT EXISTS (SELECT 1 FROM employee WHERE job_id=jobs.job_id)

七：尽可能使用索引

创建索引后，并非每一个查询都会使用索引，在使用索引的状况下，索引的使用效率也会有很大的差异。只要咱们在查询语句中没有强制指定索引，索引的选择和使用方法是SQLSERVER的优化器自动做的选择，而它选择的根据是查询语句的条件以及相关表的统计信息，这就要求咱们在写SQL语句的时候尽可能使得优化器可使用索引。为了使得优化器能高效使用索引，写语句的时候应该注意：

（1）不要对索引字段进行运算，而要想办法作变换，好比：

SELECT ID FROM T WHERE NUM/2=100    改成   select id from t where num=100/2;

（3）不要对索引字段进行格式转换

（4）不要对索引字段使用函数

（5）不要对索引字段进行多字段链接

八：多表链接的链接条件对索引的选择有着重要的意义，因此咱们在写链接条件条件的时候须要特别注意

A、多表链接的时候，链接条件必须写全，宁肯重复，不要缺漏。

B、链接条件尽可能使用汇集索引

C、注意ON、WHERE和HAVING部分条件的区别

ON是最早执行， WHERE次之，HAVING最后，由于ON是先把不符合条件的记录过滤后才进行统计，它就能够减小中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比HAVING快点的，由于它过滤数据后才进行SUM，在两个表联接时才用ON的，因此在一个表的时候，就剩下WHERE跟HAVING比较了。

(1) INNER JOIN

(2) LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)

(3) CROSS JOIN

其它注意和了解的地方有：

A、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减小判断的次数。

B、注意UNION和UNION ALL的区别。– 容许重复数据用UNION ALL好

C、注意使用DISTINCT，在没有必要时不要用。

D、TRUNCATE TABLE 与 DELETE 区别。

E、减小访问数据库的次数。

还有就是咱们写存储过程，若是比较长的话，最后用标记符标开，由于这样可读性很好，即便语句写的不怎么样，可是语句工整，C# 有region，SQL我比较喜欢用的就是：

–startof 查询在职人数

SQL语句

–end of

正式机器上咱们通常不能随便调试程序，可是不少时候程序在咱们本机上没问题，可是进正式系统就有问题，可是咱们又不能随便在正式机器上操做，那么怎么办呢？咱们能够用回滚来调试咱们的存储过程或者是SQL语句，从而排错。

BEGIN TRAN

UPDATE a SET 字段=”

ROLLBACK

做业存储过程我通常会加上下面这段，这样检查错误能够放在存储过程，若是执行错误回滚操做，可是若是程序里面已经有了事务回滚，那么存储过程就不要写事务了，这样会致使事务回滚嵌套下降执行效率，可是咱们不少时候能够把检查放在存储过程里，这样有利于咱们解读这个存储过程，和排错。

BEGIN TRANSACTION

–事务回滚开始

–检查报错

MySQL

IF ( @@ERROR0 ) BEGIN --回滚操做 ROLLBACKTRANSACTION RAISERROR('删除工做报告错误', 16, 3) RETURN END IF ( @@ERROR0 ) BEGIN --回滚操做 ROLLBACKTRANSACTION RAISERROR('删除工做报告错误', 16, 3) RETURN END –结束事务

COMMIT TRANSACTION