我們知道數據庫中的統計信息的準確性是非常重要的。它會影響執行計劃。一直想寫一篇關於統計信息影響執行計劃的相關博客，但是都卡在如何構造一個合適的例子上，所以一直拖著沒有寫。巧合，最近在生產環境中遇到這麽一個案例，下面對案例中的相關信息做了脫敏處理，有些中間步驟也省略了，只關註核心部分SQL。如下所示，同事反饋一個SQL語句執行很慢。

UPDATE  b

SET     b.[Status] = ‘已掃描，未簽收‘ ,

        b.[Time] = pr.CreatedDate

FROM    #Batch b

        JOIN
 
 WDPM.PdaRecords pr WITH ( NOLOCK ) ON b.Batch_No = pr.OrderNo

                                                              AND pr.FunctionName = ‘[WDPM].[usp_SaveOutOrder]‘

WHERE   b.[Status] = ‘已打單，未掃描‘

        AND pr.CreatedDate > b.[Time];

如下截圖所示，這個SQL語句基本上耗時271秒。一個臨時表與一個表做嵌套循環連接（Nested Loops）。 因為表WDPM.PdaRecords只有一個聚集索引，所以執行計劃中，這個表走聚集索引掃描。

註意：這裏表WDPM.PdaRecords本身缺少合適的索引，只有一個聚集索引。後面展開講述這個問題.這裏先圍繞統計信息的準確性對執行計劃的影響來展開講述。

物理表WDPM.PdaRecords的數據量為2505369（當然這個是一直在變化的。這個數值僅僅是實驗前的檢測記錄，一直有會話對其進行DML操作，所以數據會變化，所以這裏沒有列出統計信息截圖）。

我們看到Table Scan部分，預估行數（Estimated Number of Rows）為1， 實際行數為150。 這個偏差已經比較大了。

對於物理表WDPM.PdaRecords而言，基數估計的預估行數（Estimated Number of Rows）為921771， 但是由於嵌套循環連接，所以累加起來的實際行數（Actual Number of Rows）為： 921771*150 =138265650 。

我們知道嵌套循環（Nested Loops）算法的時間復雜度為N*M， N的預估值從1變成了150 ，這裏面的偏差就大了（因為每次聚集索引掃描的開銷也很大）。所以導致優化器在表的物理連接方式上選擇了嵌套循環（Nested Loops), 因為預估的代價是很小的。但是實際因為統計信息的誤差，導致這個代價放大了150倍。那麽如果我們更新臨時表的統計信息呢？然後執行這個SQL，會有什麽變化呢？

如下所示，我們在執行SQL語句前，更新一下臨時表的統計信息。發現優化器在獲取了準確的統計信息後，在表的物理連接上選擇了Hash Join方式。而且SQL語句耗時變成了1秒多。為什麽呢？ 因為優化器發現選擇Nested Loops的代價遠遠高於 Hash Join。所以它在獲取了準確的信息後，作出了最優選擇。之前之所以生成了一個錯誤的執行計劃，就是因為它得到的“信息”不準確，導致它作出了錯誤的抉擇。這個就好比你獲取了錯誤的信息，作出了錯誤的選擇，購買了一只錯誤的股票，而巴菲特由於掌握了準確的行業信息，作出了正確的選擇。 購買了幾只購票都大漲了。

UPDATE STATISTICS #Batch WITH FULLSCAN;

UPDATE  b

SET     b.[Status] = ‘已掃描，未簽收‘ ,

        b.[Time] = pr.CreatedDate

FROM    #Batch b

        JOIN WDPM.PdaRecords pr WITH ( NOLOCK ) ON b.Batch_No = pr.OrderNo

                                                              AND pr.FunctionName = ‘[WDPM].[usp_SaveOutOrder]‘

WHERE   b.[Status] = ‘已打單，未掃描‘

        AND pr.CreatedDate > b.[Time];

當然，了解到這裏，還遠遠沒有結束。我們發現表WDPM.PdaRecords 只有一個聚集索引，而且聚集索引位於Iden自增字段上，從另外一個角度來看，這個表其實是缺少合適的索引的。那麽我們可以創建一個索引。

CREATE INDEX IX_PdaRecords_N1 ON wdpm.PdaRecords(OrderNo,FunctionName)

創建索引後，即使不更新臨時表#Batch的統計信息，我們發現執行計劃也會走嵌套循環（Nested Loops)，而不會走Hash Join了。這個又是什麽原因呢？

此處截圖，是第二次執行SQL，臨時表的數據變化了（生成臨時表的數據的SQL有好幾個，每次執行獲取的數據都會有部分變化）

因為有了合適的索引，趨近準確的統計信息，以及謂詞下推（predicate push down），基數(Cardinality)的預估行數（Esitmted Row Size）為35.0545 與實際行數（Actual Number of Rows）為666， 這樣即使循環次數為140. 總的訪問記錄數為140*666=93240 ， 這個是遠遠小於之前錯誤執行計劃的138265650 。所以即使臨時表的#Batch的統計信息有誤，但是優化器還是生成了一個不錯的執行計劃。這樣SQL的執行時間也就縮短到了1秒內.

這個案例僅僅是為了展示：統計信息的準確與否，會導致優化器生成的執行計劃選擇不同的表連接方式， 例如從嵌套循環（Nested Loops)變成Hash Join。 僅僅是為了說明統計信息準確的重要性。

SQL Server統計信息偏差影響表聯結方式案例淺析