失控的查詢

有時會遇到令人費解的情況，平時一分鐘可以完成的查詢語句，某一天突然發生意外，運作了2-3個小時還在運作，這就是失控查詢的行為表現，失控的查詢（Runaway Query）是指實際執行時間比預計的時間要長的多，并且消耗大量的系統資源的查詢。通常情況下，失控的查詢是由關聯表沒有索引、關聯表使用錯誤的索引、或者選擇的join算法不恰當導緻的。

舉個例子，把TableA 和 TableB進行連接配接（join）操作，這兩個表各有100萬行，如果使用Loop Join算法，那麼有100萬*100萬次循環，時間複雜度是O(nm）。如果使用Merge Join，那麼隻需要對資料進行排序，執行歸并排序就可以了，平均時間複雜度是O(n * log m)。從時間複雜度上，可以看出Merge Join的時間複雜度比Loop Join小很多，如果Join操作使用Merge Join，将是最優的選擇。

但是，當統計資訊不能準确描述資料整體時，可能誤導查詢優化器做出錯誤的決策，如果查詢優化器選擇Loop Join算法生成執行計劃時，那麼該query會在SQL Server 内部進行海量的循環操作，使得查詢執行的時間暴增，CPU和IO資源的消耗也大幅增加。

為了避免在産品環境中出現失控查詢，可以采用以下措施：

• 為表建立索引
• 保持統計資訊及時更新
• 在腳本中使用可索引化條件

參考文檔：

作者

：悅光陰

出處

：http://www.cnblogs.com/ljhdo/

本文版權歸作者和部落格園所有，歡迎轉載，但未經作者同意，必須保留此段聲明，且在文章頁面醒目位置顯示原文連接配接，否則保留追究法律責任的權利。