SQL Server查询优化的实际操作建议描述

此文章主要向大家讲述的是SQL Server查询优化的实际操作建议，在实际操作中有些查询本身就对资源的消耗很大。这与基本的数据库与索引的相关问题有关。这些查询的效率并不低，因为SQL Server查询优化器会以最有效的可能方式实现这些查询。

然而，它们确实消耗大量资源，而且 Transact-SQL 面向 *** 的性质使这些查询看起来效率很低。SQL Server查询优化器的智能水平无法消除这些构造的固有资源成本。与不复杂的查询相比，这些查询的固有成本十分昂贵。虽然 microsoft® SQL Server™ 2000 使用更佳的访问计划，但受到基础构造可能性的限制。例如，下列类型的查询可能占用大量资源：

返回大结果集的查询

高度不唯一的 WHERE 子句

不过有一些针对优化查询和提高查询性能的建议，其中包括：

添加更多的内存（尤其是假如服务器运行许多复杂查询而且其中几个查询执行很慢）。

在有多个处理器的计算机上运行 SQL Server。多个处理器使 SQL Server 得以利用并行查询。

考虑重新编写查询

假如查询使用游标，则确定假如使用效率更高的游标类型（如快速只进游标）或单纯查询能否更有效地编写游标查询。单纯查询的性能一般优于游标操作。一组游标语句通常是一个外循环操作，在此操作中，一旦使用内部语句便开始处理外循环内的每行，因此可考虑使用 GROUP BY 或 CASE 语句或改为使用子查询。

假如应用程序使用循环，可考虑在查询内放入循环。应用程序常包含带参数化查询的循环，该循环执行许多次并要求运行应用程序的计算机与 SQL Server 之间有 *** 往返。可改为使用临时表创建一个更复杂的查询。只需提供一个 *** 往返，SQL Server查询优化器即会更好地优化这个查询。

不要对同一查询内的单个表使用多个别名以模拟索引交叉。模拟索引交叉已没有必要，因为 SQL Server 会自动考虑索引交叉并且可以在同一查询内的相同表上使用多个索引。例如，给出下列示例查询：

SELECT * FROM lineitem WHERE partkey BETWEEN 17000  AND 17100 AND shipdate BETWEEN '1/1/1994' AND '1/31/1994"  

SQL Server 可以在 partkey 和 shipdate 列上都使用索引，然后在两个子集之间执行哈希匹配以获得索引交叉。

只在必要时才使用查询提示。若查询使用在 SQL Server 早期版本上执行的提示，则应在不指定提示的情况下对该查询进行测试。提示会防碍SQL Server查询优化器选择更好的执行计划。

利用 query governor 配置选项和设置。可以使用 query governor 配置选项阻止执行长时间运行的查询，从而防止消耗系统资源。默认情况下，query governor 配置选项允许执行所有查询，而不考虑查询所需的时间。

然而，可以将查询调控器设置到更大秒数，以允许执行所有连接的所有查询或只允许执行特定连接的查询。查询调控器基于估计的查询成本而不是实际的已用时间，因此没有任何运行时开销。它还在长时间运行的查询开始前便将其停止，而不是先运行这些查询直到达到某些预定义的限制为止。