1

次のようなSQLクエリがあります。

WITH RES_CTE AS
  (SELECT
  COLUMN1,
  COLUMN2,
  [MORE COLUMNS...]
  ROW_NUMBER() OVER (ORDER BY R.RANKING DESC) AS RowNum 
  FROM TABLE1 As R, TABLE2 As A, TABLE3 As U, TABLE4 As S, TABLE5 As T 
  WHERE R.RID = A.LID 
  AND S.QRYID = R.QRYID
  AND A.AID = U.AID
  AND CONDITION1 = 'VALUE'
  AND CONDITION2 = 'VALUE'
  AND [MORE CONDITIONS...]
),
Results_Cnt AS 
  (SELECT COUNT(*) CNT FROM Results_CTE)
SELECT * FROM Results_CTE, Results_Cnt WHERE RowNum >= 1 AND RowNum <= 25

現在、このクエリは通常1秒未満で実行され、に基づいて5000から25レコードを返しますCONDITION1。

ただし、最近、aに新しい列を追加し、TABLE1その値をCONDITION2上記のクエリでaとして使用しました。列は今後入力されますが、過去のすべての値はNULLです。

NULL実行が遅い理由である結合テーブルの上の何かを読みました。テーブルには約130万件のレコードがあります。それらの90％はNULL問題のある列にあります。しかし、その列は結合されていません。（参加しているのはINDEX）

ただし、新しい列を作成し、次のようにデータをコピーするだけで、とにかくそれを試してみたかったのです。

ALTER TABLE TABLE1 ADD COL_NEW
UPDATE TABLE1 SET COL_NEW = COL_OLD

次のステップは、NULLを実際の値に置き換えることでしたが、最初に、キックのためだけに、新しいフィールドCOL_NEWを条件として使用するようにクエリを変更し、問題は解決しました。

問題がなくなってよかったのですが、自分で説明することはできません。NULLとは何の関係もないのに、そもそも実行が遅いのはなぜですか？

更新：問題はキャッシュされたクエリプランが原因である可能性があります。したがって、問題は本質的に、クエリプランを強制的に更新する方法になります。

更新：ALTER TABLE実行すると実行プランが更新された可能性がありますが、問題が返されました。何が起こっているのかをどうやって知ることができますか？

4

1 に答える 1

0

新しい列の統計が完全に null でいっぱいであることを示している間に、クエリ プランがキャッシュされ、テーブル スキャンが強制されたようです。ALTER TABLE に続いて、クエリ プランが更新され、テーブル スキャンが再びインデックス lookujp に置き換えられ、パフォーマンスが通常に戻りました。

それが起こったことかどうかを確実に知る唯一の方法は、両方のクエリのクエリ プランを調べることですが、それらは今ではとうの昔になくなっています。

于 2013-03-15T05:40:11.560 に答える