2010-12-20 12 views
6

私たちは多少複雑なSQL更新クエリを持っていますが、これは月に数回実行されます。ほとんどの場合、実際には高速で実行されているようですが、一部のデータベースでは非常に時間がかかります。関係するテーブルで "UPDATE STATISTICS"を実行すると、アップデートはただちに再びすぐに実行されます。最後にデータベースのすべてのテーブルに対してUPDATE STATISTICSを呼び出す夜間タスクを設定しました。しかし、それは問題を解決していないようだ。私たちはまだ毎回手動で "UPDATE STATISTICS"を実行する必要があります。なぜ統計は非常に古くなってしまいますか?統計情報がSQL Serverで古くなってしまうのはなぜですか?

UPDATE DataTableA 
SET DataTableA.IndexedColumn1 = 123456789, DataTableA.Flag1 = 1 
FROM DataTableA WITH (INDEX(IX_DataTableA)) 
INNER JOIN GroupingTableA ON GroupingTableA.ForeignKey1 = GroupingTableA.PrimaryKey 
INNER JOIN LookupTableA ON DataTableA.ForeignKey3 = LookupTableA.PrimaryKey 
LEFT OUTER JOIN GroupingTableB ON DataTableA.IndexedColumn2 = GroupingTableB.IndexedColumn2 
WHERE GroupingTableB.IndexedColumn1 = 123456789 
AND DataTableA.IndexedColumn1 IS NULL 
AND DataTableA.IndexedColumn2 IN (... 300 entries here ...) 
AND DataTableA.Deleted = 0 
AND GroupingTableA.Date <= GroupingTableB.EndDate 
AND GroupingTableA.Date >= DATEADD(month, -1, GroupingTableB.StartDate) 
AND LookupTableA.Column2 = 1 
AND DataTableA.Status1 IN (1, 3) 
AND DataTableA.Status2 NOT IN (1, 3, 9) 

DataTableAは、数百万行が含まれています

は、ここのようなクエリが見えるものの約です。
GroupingTableAおよびGroupingTableBにはそれぞれ数万行が含まれています。
LookupTableAには数十の行が含まれています。
インデックスIX_DataTableAは、私はあなたが特定のインデックス(WITH (INDEX(IX_DataTableA))

はあなたがよろしいを使用するように強制されている場合は、あなたの統計が同じくらい重要ではないと思います(IndexedColumn1のASC、IndexedColumn2のASC)

+0

試行錯誤の結果、上の例のGroupingTableBは古くなっていると判断しました。問題は引き続き発生しますが、挿入するたびにそのテーブルで "UPDATE STATISTICS"を呼び出すことで回避しました。正確には理想的な解決策ではありません... –

+0

この質問は古いですが、WHERE句の 'GroupingTableB'に条件を置くと、それは論理的に' LEFT JOIN'を 'INNER JOIN '。このような3つの条件があります。 'LEFT JOIN'が実際に適切な' OUTER'結合として機能するようにするには、それらの条件を 'LEFT JOIN'の' ON'節に移動する必要があります。私はちょうどsayin 'だ... :) – ErikE

答えて

3

上の指標でありますオプティマイザよりもよく知っている?

私は高速更新と遅い更新のための実行計画を見ることによって開始する。また

は、レコード数が速い/遅いクエリに匹敵する更新されている?

+0

良い呼び出し@Abe Miessler - @ブライスワグナーはUDPATEは新しい実行計画を使用するため、統計を更新した後に改善が見られるかもしれません。 – bobs

+0

この場合、オプティマイザよりよく分かっていると思いますが、特定の状況では完全に関係のないインデックスでインデックススキャンを行っていました。オプティマイザの問題のほとんどを修正したWITH INDEXを含め、私はちょうどそれがなぜそれらのすべてを修正しなかったのか混乱しています。 –

+0

私はそれが遅い実行しているときに推定された実行計画を見ました、それはインデックスをしている時間の92%が私の強制的なインデックスを求めていると言いました。 –

1

自動統計がオンで、エンジンは

Table Type | Empty Condition | Threshold When Empty |Threshold When Not Empty 
_________________________________________________________________________________ 
Permanent | < 500 rows  | # of Changes >= 500 | # of Changes >= 500 + (20% of Cardinality) 
___________________________________________________________________________ 
Temporary | < 6 rows  | # of Changes >= 6 | # of Changes >= 500 + (20% of Cardinality) 

しかし、なぜ推測を取らないと、単にプランガイドを展開:通常の方法より頻繁に毎晩よりも、統計quite oftenを更新したいとウルド? Understanding Plan Guidesを参照してください。

+0

私は、その最初のリンクから "sp_autostats "を使用して、インデックス上で統計情報が有効になっていることを確認しました。私はまた "sp_dboption 、 'auto create statistics'、 'on'"を実行して、実際に(ボックスがチェックされていても)実際にオンになっていることを確認しました。来週はそれがうまく行かない場合は、プランガイドを作成します。 –

+0

自動統計フラグを使いこなすことは効果がなかったので、私はプランガイドを調査し始めました。彼らは2000年ではなくSQL 2005以降にしか適用されません。 –

関連する問題