有些查詢天生就消耗大量資源。這與基本的數據庫和索引問題有關。這些查詢的效率并不低，因為查詢優化器會以最有效的可能方式實現這些查詢。然而，它們確實消耗大量資源，而且 transact-sql 面向集合的性質使這些查詢看起來效率很低。查詢優化器的智能水平無法消除這些構造的固有資源成本。與不復雜的查詢相比，這些查詢的固有成本十分昂貴。雖然 microsoft(r) sql server? 2000 使用最佳的訪問計劃，但受到基礎構造可能性的限制。

例如，下列類型的查詢可能占用大量資源：

返回大結果集的查詢

高度不唯一的 where 子句
不過有一些針對優化查詢和提高查詢性能的建議，其中包括：

添加更多的內存（尤其是如果服務器運行許多復雜查詢而且其中幾個查詢執行很慢）。

在有多個處理器的計算機上運行 sql server。多個處理器使 sql server 得以利用并行查詢。有關更多信息，請參見并行查詢處理。

考慮重新編寫查詢。
如果查詢使用游標，則確定如果使用效率更高的游標類型（如快速只進游標）或單純查詢能否更有效地編寫游標查詢。單純查詢的性能一般優于游標操作。一組游標語句通常是一個外循環操作，在此操作中，一旦使用內部語句便開始處理外循環內的每行，因此可考慮使用 group by 或 case 語句或改為使用子查詢。

如果應用程序使用循環，可考慮在查詢內放入循環。應用程序常包含帶參數化查詢的循環，該循環執行許多次并要求運行應用程序的計算機與 sql server 之間有網絡往返?？筛臑槭褂门R時表創建一個更復雜的查詢。只需提供一個網絡往返，查詢優化器即會更好地優化這個查詢。

不要對同一查詢內的單個表使用多個別名以模擬索引交叉。模擬索引交叉已沒有必要，因為 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 早期版本上執行的提示，則應在不指定提示的情況下對該查詢進行測試。提示會防礙查詢優化器選擇更好的執行計劃。有關更多信息，請參見 select。
利用 query governor 配置選項和設置?？梢允褂?query governor 配置選項阻止執行長時間運行的查詢，從而防止消耗系統資源。默認情況下，query governor 配置選項允許執行所有查詢，而不考慮查詢所需的時間。然而，可以將查詢調控器設置到最大秒數，以允許執行所有連接的所有查詢或只允許執行特定連接的查詢。查詢調控器基于估計的查詢成本而不是實際的已用時間，因此沒有任何運行時開銷。它還在長時間運行的查詢開始前便將其停止，而不是先運行這些查詢直到達到某些預定義的限制為止。有關更多信息，請參見 query governor cost limit 選項和 set query_governor_cost_limit。