MS SQlサーバー2008でISNULL
を使用しています。テーブルが大きすぎるため、ISNULL
を使用するとパフォーマンスに影響を与える可能性がありますか?.
前もって感謝します
これを使用する必要がある場合、ISNULLとCOALESCEまたはCASEなどの代替との違いはごくわずかです。心配しないで
違いは、データ型の処理方法にあります。 COALESCE/CASEは暗黙的なデータ型変換を追加できますが、ISNULLはより単純なルールを持っています。
編集する
SELECTリストでISNULLを使用してNULLSを抑制するのは簡単です。主な作業は、行とデータの処理です。余分なISNULLは測定できません:しない 時期尚早に最適化
Select-clauseのISNULL()は、パフォーマンスにほとんど影響を与えません。一方、where節では、オプティマイザがその列でインデックスを使用するのを妨げるため、パフォーマンスに非常に大きな影響を与える可能性があります。
where isnull(col1, 0) = 0 -- unable to use index, because every
-- row has to be evaluated
where col1 = isnull(@myVar, 0) -- index will be used, since isnull(@myVar, 0)
-- returns the same static value for every row and
-- not every row has to be evaluated by the function.
そのため、where句でisnull()を使用する場合は、クエリオプティマイザーがインデックスを使用できないようにするかどうかを評価してください。その場合は、isnull(col1、0)という結果を持つ計算列を作成し、計算列にインデックスを付けて、where節で使用することを検討してください。
はい、できます。オプティマイザーの場合、クエリを(可能であれば)フォームに書き換える方が良い
(Field = @x OR @x IS NULL)
特定の場合に関数を使用すると、オプティマイザが統計を使用できなくなり、場合によっては暗黙的なデータ型変換が強制されるため
Where句でisNullを使用しないでください。参照 この記事 。
Replace_valueとしてサブクエリを指定してISNULLを使用する場合は注意してください。
Check_expressionの値がNULLでなくてもパフォーマンスが低下しない場合でも、サブクエリを実行するようです。
CASEは期待どおりに動作します。
はい、SQL Server Studio 2012にパフォーマンスの問題があります。
ISNULL
をOVER
と組み合わせて使用した場合、問題はかなり明白です。最適化した後(つまり、ISNULL
をサブクエリに入れてOVER
onを使用)、実行時間が(推定)25.2時間から102秒に短縮されました。
私の推測はISNULL
は列全体に対して実行する場合(たとえば、平凡なSELECT
の場合)で問題ありません。ただし、OVER
を指定して実行すると、毎回新しく呼び出されるため、パフォーマンスが低下します。
さらにドリルダウンする準備ができていません。他の人の参照用にここに置くだけです。
すでに述べたように、それはクエリでどのようにどこで使用するかによって異なります。クエリでの使用方法を表示したい場合があります。
また、これを検討することをお勧めします- SQLステートメントを検索可能にするもの
それはあなたがそれをどのように使用しているかに依存しますが、両方の場合(ISNULL()とそれなしで) 実行プランを構築できます で、結果を比較します。