重中之重---语句执行顺序
我们先看看语句的执行顺序，这是《SQL SERVER 2005技术内幕--查询》这本书的开篇第一章第一节。书的作者也要让读者首先了解语句是怎么样的一个执行顺序，因为不知道顺序何谈写个好语句。
查询的逻辑执行顺序：
- FROM <left_table>
- ON <join_condition>
- <join_type> JOIN <right_table>
- WHERE <where_condition>
- GROUP BY <group_by_list>
- WITH {cube | rollup}
- HAVING <having_condition>
- SELECT
- DISTINCT
- ORDER BY <order_by_list>
- <top_specification> <select_list>
标准的SQL 的解析顺序为：
- FROM 子句 组装来自不同数据源的数据
- WHERE 子句 基于指定的条件对记录进行筛选
- GROUP BY 子句 将数据划分为多个分组
- 使用聚合函数进行计算
- 使用HAVING子句筛选分组
- 计算所有的表达式
- 使用ORDERBY对结果集进行排序
执行顺序：
- FROM：对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1
- ON：对vt1表应用ON筛选器只有满足 <join_condition> 为真的行才被插入vt2
- OUTER(join)：如果指定了 OUTER JOIN保留表(preserved table)中未找到的行将行作为外部行添加到vt2 生成t3如果from包含两个以上表则对上一个联结生成的结果表和下一个表重复执行步骤和步骤直接结束
- WHERE：对vt3应用 WHERE 筛选器只有使 <where_condition> 为true的行才被插入vt4
- GROUP BY：按GROUPBY子句中的列列表对vt4中的行分组生成vt5
- CUBE|ROLLUP：把超组(supergroups)插入vt6 生成vt6
- HAVING：对vt6应用HAVING筛选器只有使 <having_condition> 为true的组才插入vt7
- SELECT：处理select列表产生vt8
- DISTINCT：将重复的行从vt8中去除产生vt9
- ORDER BY：将vt9的行按order by子句中的列列表排序生成一个游标vc10
- TOP：从vc10的开始处选择指定数量或比例的行生成vt11 并返回调用者
我们了解了SQL Server的执行顺序，请以前不知道的看官们，反复试验反复记忆！那么我们就接下来进一步养成日常sql好习惯，也就是在实现功能的同时又考虑性能的思想！
常用优化方法
只返回需要的数据
返回数据到客户端至少需要数据库提取数据、网络传输数据、客户端接收数据以及客户端处理数据等环节，如果返回不需要的数据，就会增加服务器、网络和客户端的无效劳动，其害处是显而易见的，避免这类事件需要注意：
横向来看：
- 不要写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中。
- 使用临时表降低语句复杂性，要降低临时表的数据量，也就是要把有条件的表尽量关联并做成临时表。
- 前面提到的隐式转换，索引字段使用计算或函数，也会导致数据不能尽早筛选。
循环改批量
循环单条操作，请改成批量操作，如果没办法修改，请尽量想办法修改！这算是最常见的吧：
- 应用代码端一记 for 循环再恶心点的每次打开关闭连接，跑个几分钟，数量大点几小时。请把你的每次for循环出来的结果放在一个datatable，list啥的，不要找到一条就往数据库写一条！
- 数据库中的游标也是差不多的道理，如果有可能不用游标循环一条一条处理，请尽量不要使用。如果自己认为必须用，也请问问别人是否可以有其他方式做批量！
- 如果没法避免一条一条的写入，那么在处理前显示开启一个事务 begin tran 在处理完成后 commit 这样也要比不开显示事务会快很多！
降低语句复杂性
降低语句复杂性是常见的优化方式。这里在说一下，导致语句特别复杂一般有两个原因：
- 程序逻辑本身就很复杂，需要很多表连接，又要排序又要聚合，时不时来几个子查询，外加几个函数。
- 由于业务有很大的共性，所以创建出很多视图，甚至视图嵌套很多层视图，最后外层又要关联单个模块的特殊性表。
对于第一种情况，代码看起来就很长很复杂，看起来很牛逼的代码其实在高手看来都是很LOW的。而对于第二种，看起来代码很简洁，但经过SQL优化器的二次编译，其实和第一种并无区别。这两种的解决办法都是降低复杂性，把一些能拆分出来的尽量拆分出来放入临时表或者表变量中，比如先把条件筛选性较强的几张表关联，然后把结果放入临时表，在用临时表和其他表关联。可以理解成我有10张表关联，我先拿5张表出来关联，然后把结果放入临时表，再跟另外5张表关联。这样这个查询的复杂度由10张表的联合变成 5+6，这样降低了复杂语句复杂度。复杂视图也是如此，在视图和外层关联前，放入临时表，再跟外层关联。子查询也是如此，可以分离出来成为临时表的子查询，先分离出来。
高能预警：这里说的是适当使用临时表，我遇到的很多开发人员一般都有这样一个过程。开始巨复杂的语句，知道使用临时表以后，每个步骤很小的操作都要用临时表。这会给你的TempDB造成很大的压力！
避免重复读取
曾经遇到过很多这样的程序，类似对商品有多种分析，而每种分析要做一些不同的处理，但是他们都会读取同一份基础数据商品和商品明细等。很多程序都是按照每种分析作为一个单独的存储过程去处理，那么也就是说有20种处理他们创建了20个存储过程，并且每个存储过程的第一步，就是先读取基础数据--商品和明细等等。不巧的是商品和商品明细有巨大的数据量，虽然做了分表（按照月份，每个表大概2QW数据），但是每个存储过程要读取一年的数据，大概是2QW * 12 ，这么庞大的数据巨量，查询后被放入一张temp表，20个存储过程顺序执行，也就是说这份基础数据每天晚上会被查询20次！基本上这个处理占据了系统夜间维护的所有时间，有时甚至会跑不完影响白天正常业务！
也许你看完描述就会笑，谁会把处理设计成这个样子？这不开玩笑么？没错，解决这个问题其实超简单，把20个存储过程合成一个。让基础数据的查询只查询一次，放入临时表，创建出下面逻辑处理需要的索引，在用这个临时表分别做下面所有的处理。这样一个夜间需要跑6小时以上的处理被缩短成40分钟！（当然说的有点夸张，里面还有些其他的优化。）
这里就提到一个使用临时表比较重要的问题，那就是类似上面的大量数据写入临时表，一定要用 先create 再 insert 的方式，不要直接使用 select into 临时表的方式，否则就是灾难了！
总结
说到语句优化，有太多太多的细节，需要明白原理，能看懂执行计划，并且不断积累，简单的几篇优化大全的帮助是微乎其微的，另外要动手实践，明白为什么这样写会好。
北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业，成立于2008年，创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴，卫宁健康数据平台战略合作伙伴。通过产品+服务双轮驱动的业务模式，14年间累计服务4000+客户，覆盖互联网、市政、交通、电信、医疗、教育、电力、制造业等各个领域。