2008-09-18 64 views
4

查詢優化器估計,當實際行數爲2000時,連接的結果只有一行。這會導致數據集的後續連接的估計結果爲一行,其中有些行高達30,000。SQL Server post-join rowcount低估

計數爲1時,QO爲許多連接選擇循環連接/索引搜索策略,這些連接速度太慢。我通過將可能的加入策略與WITH OPTION (HASH JOIN, MERGE JOIN)約束在一起解決了該問題,從而將總體執行時間從60+分鐘提高到了12秒。不過,我認爲QO由於行數不佳而仍然產生不太理想的計劃。我不想手動指定連接順序和詳細信息 - 有太多的查詢會影響它,因爲它是值得的。

這是在Microsoft SQL Server 2000中,具有多個表選擇的中等查詢連接到主選擇。

我認爲QO可能高估了連接許多方面的基數,期望表之間的連接列具有較少的共同行。

在聯接之前掃描索引的估計行數是準確的,它只是某些聯接後的估計行數太低。

數據庫中所有表的統計信息均爲最新並自動刷新。

早期的不良聯結之一是在所有人共有的信息通用的'人'表和大約5%的所有人屬於的專業人員表之間。兩個表(和連接列)中的聚集PK都是一個INT。數據庫高度規範化。

我認爲,問題的根源是壞的行數估計一定加入後,所以我的主要問題是:

  • 我怎樣才能解決QO的職位加入行數估計是多少?
  • 有沒有一種方法可以提示連接將會有很多行,而無需手動指定整個連接順序?

回答

3

儘管統計信息是最新的,但掃描百分比並不足以提供準確的信息。我在每個有問題的基表上通過掃描所有行來更新表上的所有統計信息,而不僅僅是默認百分比。

UPDATE STATISTICS <table> WITH FULLSCAN, ALL 

查詢還是有很多循環的連接,但連接順序是不同的,在2-3秒內運行。

0

你不能用恰當的查詢提示來刺激QO嗎?

+0

你能更具體嗎?你知道行數的提示嗎?我有一個WITH OPTION(MERGE JOIN,HASH JOIN)提示,但我想要更精確的東西。 – 2008-09-18 15:05:33