使用 EarlyTermination Timeout 優化查詢是否值得？
在執行Ola 的 IndexOptimize以重建所有索引和統計資訊後，我立即清除了數據和計劃記憶體並執行了一個非常複雜的醜陋查詢來獲得它的性能基線。查詢實際計劃顯示 ReasonForEarlyTermination=Timeout 和 Est Rows 和 Actual Rows 的偏差（實際行與 est 相比是 10,000 倍）。
我想知道這種行數不平衡是否可能是超時的結果 - 我認為在重建索引和統計資訊之後應該是合適的？
如果無法更改查詢本身，優化以 ReasonForEarlyTermination=Timeout 結尾的查詢是否有意義？由於我計劃進行一些索引調整併重新執行查詢，所以無法確定可能改進的結果，因為下一個查詢計劃創建肯定會再次超時，因此可能會有所不同，結果不同?
技術。詳細資訊：Sql Server 2008 R2 開發。埃德。10.50.6000.34 數據庫比較。80級。
我想知道這種行數的不平衡是否可能是超時的結果
幾乎無一例外，沒有。在優化開始之前執行初始基數估計。隨後的優化器轉換可能需要計算新的估計。沒有一般規則可以說哪種估計會更“準確”。
有關超時原因的更多資訊，請參閱此相關問題：
我認為重建索引和統計資訊後應該合適嗎？
您有“一個非常複雜的醜陋查詢”。在這種情況下期望基數估計器能很好地工作是不合理的。嘗試從單列（可能是採樣的）統計直方圖和單值密度資訊中自己計算估計值，以了解這一點。
隨著查詢複雜性的增加，估計的質量往往會下降。這是不可避免的，如果你認為一個估計的輸入通常是另一個估計的輸出。因此，錯誤往往會累積。使用“醜陋”（閱讀：非關係或其他難以估計的）條件會使情況變得更糟。
如果無法更改查詢本身，優化以 ReasonForEarlyTermination=Timeout 結尾的查詢是否有意義？
當然（但與任何其他有問題的計劃沒有什麼不同）。一般來說*，*可以分解查詢，使用不同的語法來表達它，或者可以使用一百種不同“技巧”中的任何一種。
即使查詢本身無法更改，如果可以找到好的計劃，也可以通過計劃指南強制執行。更一般地說，添加新的統計資訊和/或索引可以為優化器和基數估計器提供更好的資訊。這也會以復雜的方式影響通過優化器的程式碼路徑。我不會嘗試列出除了更改查詢文本之外可以做的所有事情。
…下一個查詢計劃創建肯定會再次超時，因此可能會有所不同，產生不同的結果？
關鍵是，通過提供更好的資訊或數據訪問方法，您通常會提高獲得良好計劃的機會。優化器不是隨機的，因此對於給定的數據庫狀態，將選擇相同的計劃，而不管超時或其他終止原因。
當然，成功的真正關鍵是避免“非常複雜醜陋”的查詢。