一、如何打开执行计划？
在Microsoft SQL Server Management Studio中打开“包括实际的执行计划”（快捷键：Ctrl+M），执行SQL语句就可以看到实际的执行计划（图文格式，非常直观），这无疑是最友好的查阅方式。
二、如何看懂实际执行计划？
执行复杂的脚本之后，看到的执行计划，很多人直接懵圈了，这些图文到底是什么含义呢，又该如何优化呢？
下面将列举常见的执行计划操作：
Table Scan（全表扫描）：如果你的表数据量非常小，表扫描是可以的，并且可能性能会比其他扫描方式好一些；如果是一张大表，这时你必须要优化索引了。大数据量时，全表扫描，性能消耗是非常明显的。
Clustered Index Scan（聚集索引扫描）：一般来讲，此时也应该优化查询语句和索引。出现聚集索引扫描，可能因为返回数据的行或列过多、或者没有明确的WHERE条件触发索引。此类扫描，应当考虑创建合适的索引、增加更加严格的返回列限定、缩小查询的数据范围以控制返回行数。
Index Seek（索引查找）：此时性能是比较好的，表示使用了非聚集索引查找。
Clustered Index Seek（聚集索引查找）：使用聚集索引（主键）查找，实际上这是SQL Server能做的最快的索引查找类型。
Bookmark Lookup（书签查找）：也是应当考虑优化的。在SELECT、JOIN、WHERE的字段中都无法使用非聚集索引来满足查找，查询优化器不得不使用额外的聚集索引查找满足查询需求的字段此时可能会引起书签查找，不过查询优化器可能也会使用Clustered Index Scan来替代书签查找。还有一个可能引起书签查找的原因是SELECT * FROM …，所以任何情况下使用SELECT * 都是不建议的。
Stream Aggregate（流聚合）：使用了SQLSERVER的聚合函数时，会引起流聚合操作。比如：COUNT,MAX,MIN,AVG,DISTINCT,SUM等。
Compute Scalar（计算标量）：使用COUNT计数时，会引起该操作；
Sort（排序）：当使用了无索引的字段排序时，可能会引起Sort操作；此时应该考虑是否需要该排序操作，或采用其他创建索引的字段排序。如确实无法改变，则建议在排序字段添加索引。
三、常见的索引优化规则
1，所有的索引优化都是取决于数据量大小，数据量极小时，可不考虑创建索引，创建了索引反而引起性能下降；
2，频繁查询、排序或者使用的条件字段，建议使用索引优化；如：存在自增主键时，如果使用创建时间排序，尽量优化为使用主键排序；
3，WHERE条件中的表达式尽量放在操作符之后。常见的条件操作符有：=、>、<、!=、BETWEEN AND 等；
举例：DATEPART(YEAR,CreateTime)>=2017 应该优化为：CreateTime>’2017-01-01 00:00:00’；LEN(ParamValue)=0 应该优化为：0=LEN(ParamValue)；
4，存在的值重复性较高的字段，不建议创建索引，如：状态标识列；
5，经常组合使用的多个条件字段，应该创建复合索引；
6，减少LIKE的使用，LIKE在使用通配符开头（如：LIKE ‘%A%’）不会使用索引查询；
7，大字段禁止创建索引；
8，不能滥用索引，必须根据实际需要是创建和维护。索引会引起磁盘和数据维护的开销，要知道，服务器的硬盘是非常可贵的。
附：好玩的系统查询脚本
1，查询引用了某个字符的数据库对象，适用于查找使用了某个字段的存储过程、视图等；
SELECT so.name, sc.text FROM dbo.syscomments sc , dbo.sysobjects so
WHERE sc.id = so.id AND sc.text LIKE ‘%PlatValue%‘
--AND so.xtype = ‘p‘ --xtype表示对象类型，p为存储过程
ORDERBY name
2，查询某个表的表结构
SELECT sc.name, st.name AS [DataType], sc.prec
FROM syscolumns sc
INNER JOIN systypes st ON st.xusertype = sc.xusertype
WHERE sc.id = OBJECT_ID(‘PlatParam‘)
