SQL语句的优化建议

时间 2019-11-17

标签 sql 语句优化建议栏目 SQL 繁體版

原文原文链接

重中之重---语句执行顺序前端

咱们先看看语句的执行顺序面试

若是我没记错这是《SQL SERVER 2005技术内幕--查询》这本书的开篇第一章第一节。书的做者也要让读者首先了解语句是怎么样的一个执行顺序，由于不知道顺序何谈写个好语句？sql

查询的逻辑执行顺序：数据库

(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}sqlserver

(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对结果集进行排序

执行顺序：

1.FROM：对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1

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

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

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 并返回调用者

　　咱们了解了sqlserver执行顺序，请之前不知道的看官们，反复试验反复记忆！那么咱们就接下来进一步养成平常sql好习惯，也就是在实现功能的同时又考虑性能的思想！

设计思路

　　设计思路说的有点大了，下面介绍几个最多见的设计问题！

　　循环改批量

　　循环单条操做，请改为批量操做，若是没办法修改，请尽可能想办法修改！这算是最多见的吧：

应用代码端一记 for 循环再恶心点的每次打开关闭链接，跑个几分钟，数量大点几小时。请把你的每次for循环出来的结果放在一个datatable，list啥的，不要找到一条就往数据库写一条！
数据库中的游标也是差很少的道理，若是有可能不用游标循环一条一条处理，请尽可能不要使用。若是本身认为必须用，也请问问别人是否能够有其余方式作批量！
若是无法避免一条一条的写入，那么在处理前显示开启一个事务 begin tran 在处理完成后 commit 这样也要比不开显示事务会快不少！

　　上个小例子：

create table test_0607 (a int,b nvarchar(100))

declare @i int 
set @i = 1

while @i < 10000
begin 
insert into test_0607
select @i,'0607无显示总体事务'
set @i = @i + 1
end

drop table test_0607
create table test_0607 (a int,b nvarchar(100))

---加上事务
begin tran
declare @i int 
set @i = 1
while @i < 10000
begin 
insert into test_0607
select @i,'0607 显示总体事务'
set @i = @i + 1
end
----结束事务，提交
commit

结果： 8秒和0.8秒的区别，不用多说啥了吧！凡事有利有弊，这种显示开启大事务要保证的总体的过程不会执行特别长的时间，若是执行的操做特别多并且时间长就是灾难了！

　　下降语句复杂性

　　前文语句优化三板斧中已经介绍过，下降语句复杂性是常见的优化方式。这里在说一下，致使语句特别复杂通常有两个缘由：

程序逻辑自己就很复杂，须要不少表链接，又要排序又要聚合，时不时来几个子查询，外加几个函数。
因为业务有很大的共性，因此建立出不少视图，甚至视图嵌套不少层视图，最后外层又要关联单个模块的特殊性表。

　　对于第一种状况，代码看起来就很长很复杂，看起来很牛逼的代码其实在高手看来都是很LOW的。而对于第二种，看起来代码很简洁，但通过SQL优化器的二次编译，其实和第一种并没有区别。这两种的解决办法都是下降复杂性，把一些能拆分出来的尽可能拆分出来放入临时表或者表变量中，好比先把条件筛选性较强的几张表关联，而后把结果放入临时表，在用临时表和其余表关联。能够理解成我有10张表关联，我先拿5张表出来关联，而后把结果放入临时表，再跟另外5张表关联。这样这个查询的复杂度由10张表的联合变成 5+6，这样下降了复杂语句复杂度。

　　复杂视图也是如此，在视图和外层关联前，放入临时表，再跟外层关联。

　　子查询也是如此，能够分离出来成为临时表的子查询，先分离出来。

　　对于表值函数，其实也是有内联和表值之分：

---方式1：内联

 CREATE FUNCTION [dbo].[tvf_inline_Test]()
 RETURNS TABLE
 AS
    RETURN
     SELECT  ProductID
     FROM    Sales.SalesOrderHeader soh
             INNER JOIN Sales.SalesOrderDetail sod ON soh.SalesOrderID = sod.SalesOrderID 
---此写法能够结合外层查询二次编译（也就是能够利用外层的关联条件及WHERE 条件）

---方式2：表值

CREATE FUNCTION [dbo].[tvf_multi_Test]()
 RETURNS @SaleDetail TABLE ( ProductId INT )
 AS
     BEGIN 
         INSERT  INTO @SaleDetail
                 SELECT  ProductID
                 FROM    Sales.SalesOrderHeader soh
                         INNER JOIN Sales.SalesOrderDetail sod ON soh.SalesOrderID = sod.SalesOrderID 
         RETURN 
     END

---此写法不能应用外层条件筛选，若是数据量大会对性能产生影响。

　　高能预警：这里说的是适当使用临时表，我遇到的不少开发人员通常都有这样一个过程。开始巨复杂的语句，知道使用临时表之后，每一个步骤很小的操做都要用临时表。这会给你的TempDB形成很大的压力！

　　避免重复读取

　　曾经遇到过不少这样的程序，相似对商品有多种分析，而每种分析要作一些不一样的处理，可是他们都会读取同一份基础数据商品和商品明细等。不少程序都是按照每种分析做为一个单独的存储过程去处理，那么也就是说有20种处理他们建立了20个存储过程，而且每一个存储过程的第一步，就是先读取基础数据--商品和明细等等。不巧的是商品和商品明细有巨大的数据量，虽然作了分表（按照月份，每一个表大概2QW数据），可是每一个存储过程要读取一年的数据，大概是2QW * 12 ，这么庞大的数据巨量，查询后被放入一张temp表，20个存储过程顺序执行，也就是说这份基础数据天天晚上会被查询20次！基本上这个处理占据了系统夜间维护的全部时间，有时甚至会跑不完影响白天正常业务！

　　　也许你看完描述就会笑，谁会把处理设计成这个样子？这不开玩笑么？没错，解决这个问题其实超简单，把20个存储过程合成一个。让基础数据的查询只查询一次，放入临时表，建立出下面逻辑处理须要的索引，在用这个临时表分别作下面全部的处理。这样一个夜间须要跑6小时以上的处理被缩短成40分钟！（固然说的有点夸张，里面还有些其余的优化，√）

　　　　这里就提到一个使用临时表比较重要的问题，那就是相似上面的大量数据写入临时表，必定要用先create 再 insert 的方式，不要直接使用 select into 临时表的方式，不然就是灾难了！

论索引的重要性

　　　　老生常谈的话题了，我想全部公司招人的时候都会问到这样的面试题：什么是索引，索引有哪些类，有何不一样？等等....

　　　　索引是啥？什么是汇集索引？什么是非汇集索引？什么是主键查找？什么是主键扫描？什么是索引查找？什么是书签查找？有啥区别？ 这里都不介绍，请自行百度！

　　　　不少开发人员意识不到索引到底对语句，甚至对系统有对重要。关于索引对系统的重要性请关注后续文章。

　　　　如何创建索引

　　　　最为简单粗暴的方式，当你写完一条语句的时候，打开执行计划，执行一下按照优化器的提示建立索引。

　　　　高能预警：这里须要你的条件能够用索引！好比你的语句中索引列不能带函数，不能参与计算如 where productID/2 = @a ，不能有隐式转换等！

　　　　创建索引后，一样并非每一个查询都会使用索引，在使用索引的状况下，索引的使用效率也会有很大的差异。如上面缺失的索引咱们添加上之后再查询！

　　　　索引查找（seek），通常为最优（但查找也要看查找的筛选性），尽可能吧where 条件中的字段建成一个组合索引，而且包含要查询select 中的字段。这里就不继续深刻了。

　　　　看懂执行计划建立

　　　　如何看懂执行计划这就是一个能够写几百页书的话题了，可是看懂执行计划是作优化的重中之重了！之后的文章中会详细讲解。

　　　　经过执行计划能够看出语句的主要消耗到底在哪里，另外配合set statistics io on 等分析读次数，也是优化的关键，建立或优化索引页是主要从这里出发。

语句常规习惯

　　只返回须要的数据

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

　　横向来看：

不要写SELECT * 的语句，而是选择你须要的字段。
当在SQL语句中链接多个表时, 请使用表的别名并把别名前缀于每一个Column上.这样一来,就能够减小解析的时间并减小那些由Column歧义引发的语法错误。

　　纵向来看：

where 条件要尽可能的多且保证高筛选性。
业务中很常见要返回大批量数据到前端，可是这些数据真的都是必要的么？前端是否能够加一些默认条件呢？

　　减小没必要要的操做

　　写语句以前，理清你的思路！

杜毫不必要的表链接，多一个表连接表明多很大部分开销。
减小没必要要的条件判断，不少时候前台传入为空值得时候后台语句被写成XX=XX OR XX IS NULL OR XX LIKE OR ...OR ...OR 等。这是比较经典的问题了，请加入判断在拼入最后的条件！
你的语句须要去重复么？ distinct 、union等操做
LEFT JOIN 和 inner join的区别，是否真的须要left join，不然选用inner join 来减小没必要要的数据返回。
order by 你的语句是否须要排序？排序是否能够经过索引来下降性能消耗？我见过居然插入数据也带着order by的！

　　尽可能早的筛选

最经典的例子就是where 和 having的区别，看过语句执行顺序你应该已经明白了。能写在where 中不要放在having中。
使用临时表下降语句复杂性，要下降临时表的数据量，也就是要把有条件的表尽可能关联并作成临时表。
前面提到的隐式转换，索引字段使用计算或函数，也会致使数据不能尽早筛选。

　　经常使用的写法误区（如下都是网上片面结论）

　　全部别人提到的方法到底有无效

or 要用union all 代替（or是很常规的一种写法，状况分不少种，一个表的两个条件用 a.a =X or a.a = XX ，一个表两个字段用 a.a =X or a.b = x，两个不一样表字段用 a.a = X or b.a = X 这是网上说的union all代替的）
避免使用 in、not in （数据量小的时候不会有问题，若是数据量大可能影响性能，数据量大处理方式先把in 中的数据放入临时表）
事务操做过程要尽可能小，能拆分的事务要拆分开来。（前文中提到的例子，有些状况循环写入下，显示开启一个大事务会有很大帮助）
使用with（nolock）查询语句不会阻塞（通常状况下是这样，可是若是有架构修改或快照发布等使用with（nolock）也会阻塞）
用exists 代替 in （状况也很复杂不能一律而论）

-----------------------------------------------------------------------------------------------------

　　总结：说到语句优化，有太多太多的注意，这些须要明白原理，能看懂执行计划，而且不断积累。

　　　　　 单单的几篇优化大全是帮助是微乎其微的，另外要动手实践，明白为何这样写会好！