调整SQLSERVER非最优执行计划

我们发出的 SQL 语句，如果没有对应的缓存，优化器都会创建一个相应的 执行 计划 。但是，优化器基于成本的优化过程，在面对比较复杂的 SQL 语句时，不会考虑所有的情况。因此有些时候，就会给出一个近似高效的 执行 计划 。同时，受生产环境负载的影响，可

我们发出的SQL语句，如果没有对应的缓存，优化器都会创建一个相应的执行计划。但是，优化器基于成本的优化过程，在面对比较复杂的SQL语句时，不会考虑所有的情况。因此有些时候，就会给出一个近似高效的执行计划。同时，受生产环境负载的影响，可能优化的过程会更不彻底，因此我们就应该控制语句的复杂程度，以减少优化器考虑各种组合的可能性。

当系统的性能出现问题时，即便你的索引建的很完美，但有的时候因为选择度的问题，你还要考虑怎么样在选择度不高的时候避免对表的扫描。防止像在高速公路塞车一样，所有的查询都要等待再等待，就像公交车一样。虽然SQL2005中有INCLUDE的功能，打破了在建立非聚集索引时16个字段900个字节的限制。但包含过多的INCLUE字段的代价是浪费太多的磁盘空间。当然，我们可能不在乎磁盘空间开销，毕竟是客户买单。面对如此大的索引数据量，SQL2005也增加了备份的策略。用文件或文件组的方式来处理。但多文件或文件组的备份是基于多个备份基准的，因此给管理带来了一定的挑战性。所以，我们应该首先考虑好用既有的索引来优化查询。实在没有办法时才去考虑新建索引或调整索引的字段。没有最好的，只有追求一个更合适的索引，尽量减少创建太多的索引。因为这会给数据的修改造成负担。