SQLSERVER的SQL语句优化方式小结

2、查询SQL语句时打开“显示估计的执行计划”，分析每个步骤的情况

3、初级做法，在CPU占用率高的时候，打开SQL Server Profiler运行，将跑下来的数据存到文件中，然后打开数据库引擎优化顾问调用那个文件进行分析，由SQL SERVER提供索引优化建议。采纳它的INDEX索引优化部分。

4、但上面的做法经常不会跑出你所需要的，在最近的优化过程中CPU占用率极高，但根本提不出我需要的优化建议，特别是有些语句是在存储过程中并且多表联立。这时就需要用中级做法来定位占用CPU高的语句。

5、还是运行SQL Server Profiler，将运行结果保存到某个库的新表中（随便起个名字系统会自己建）。让它运行一段时间，然后可以用
select top 100 * from test where textdata is not null order by duration desc
这个可以选出运行时间长的语句，在ORDER BY 中可以替换成CPU、READS，来选出CPU占用时间长和读数据过多的语句。
定位出问题的语句之后就可以具体分析了。有些语句在执行计划中很明显可以看出问题所在。
常见的有没有建索引或索引建立不合理，会出现table scan或index scan，凡是看到SCAN，就意味着会做全表或全索引扫描，这是带来的必然是读次数过多。我们期望看到的是seek或键查找。

6、怎么看SQL语句执行的计划很有讲究，初学者会过于关注里面显示的开销比例，而实际上这个有时会误导。我在实际优化过程中就被发现，一个index scan的执行项开销只占25%，另一个键查找的开销占50%，而键查找部分根本没有可优化的，SEEK谓词就是ID=XXX这个建立在主键上的查找。而仔细分析可以看到，后者CPU开销0.00015，I/O开销0.0013。而前者呢，CPU开销1.4xxxx,I/O开销也远大于后者。因此，优化重点应该放在前者。

7、如何优化单个部分，一个复杂的SQL语句，SQL SERVER会很聪明地重组WHERE后的语句，试图匹配索引。选中带优化的步骤，选择旁边的‘属性”，再选择其中的“谓词”，将其中部分复制下来，这部分就是分解后的WHERE 语句，然后在查询界面中select * from 表 where 刚才复制下来的“谓词”。这个就是需要优化的部分，既然已经走到这一步了，大部分人应该能手动建立索引了，因为这里的WHERE语句比之前的肯定简单不少。（在我项目中原始SELECT语句的WHERE部分有10个条件组合，涉及6个字段，提取出来要优化的部分就4个条件，涉及到3个字段。新的索引建立后，CPU占用率一下子就降低了，而且新建立的索引涉及的字段属于不常UPDATE的部分，频繁的读写操作不会影响UPDATE的效率）

8、