SQLクエリのパフォーマンス

この特定のケースでは、30,000行がデータベースで処理するのが難しくないため、大きな違いに気付くことはありません。 ただし、数億行以上について話していた場合は、結合する前に集計することで顕著な改善が見られます。 これを行うときは、実行していることが論理的に一貫していることを確認してください—実行速度を心配する前に、作業の正確さを心配する必要があ

13クエリのパフォーマンスのヒント

オブジェクト名の前に接頭辞を付けることを忘れないでください テーブル、ストアドプロシージャ、ビュー)に所有者/スキーマ名を付けます。

理由:所有者/スキーマ名が指定されていない場合、SQL Serverのエンジンは、オブジェクトが検出されるまで、すべてのスキーマでそれを検索しようとします。 所有者/スキーマ名が指定されている場合、SQL Serverエンジンでは、その所有者/スキーマ以外のテーブルは検索されません。

*演算子

は、SELECTステートメントで*演算子を使用しません。 代わりに、列名を使用します。

理由:SQL Serverはすべての列名をスキャンし、*をSQL SELECTステートメント内のテーブルのすべての列名に置き換えます。 列名を指定すると、この検索と置換が回避され、パフォーマンスが向上します。

Nullable Columns

nullable columnsと比較するときはNOT INを使用しないでください。 代わりにNOT EXISTSを使用します。

理由:NOT INがクエリで使用されている場合(クエリがnull値の行を返さない場合でも)、SQL Serverは各結果をチェックしてnullかどうかを確認します。 NOT EXISTSを使用しても、nullとの比較は行われません。 また、NOT EXISTSは2つの状態(trueまたはfalse)のみを返しますが、NOT INは最大3つの状態(true、false、NULL)を返すことができ、期待していた結果が得られない場合があります。

テーブル変数と結合

結合でテーブル変数を使用しないでください。 結合では、代わりに一時テーブル、Cte(共通テーブル式)、または派生テーブルを使用します。

理由:テーブル変数は多くの状況で非常に高速で効率的ですが、SQL Serverエンジンはそれを単一の行と見なします。 このため、SQLは結合で使用されたときに恐ろしく実行される実行計画を生成します。

ストアドプロシージャ名

ストアドプロシージャの名前をsp_で開始しないでください。

理由:ストアドプロシージャの名前がsp_またはSP_の場合、所有者/スキーマ名が指定されていても、SQL Serverは常にsystem/masterデータベースをチェックします。 ストアドプロシージャにSP_を指定せずに名前を指定すると、SQL Serverのsystem/masterデータベースでのこの不要なチェックが回避されます。

SET NOCOUNT ONを使用

DML操作ではSET NOCOUNT ONを使用します。

理由:DML操作を実行する場合(つまり、 挿入、削除、選択、および更新)、SQL Serverは常に影響を受ける行の数を返します。 多くの結合を持つ複雑なクエリでは、これは大きなパフォーマンスの問題になります。 SET NOCOUNT ONを使用すると、影響を受ける行数が追跡されないため、パフォーマンスが向上します。

GROUP BY、ORDER BY、DISTINCTの使用は避けてください

可能な限りGROUP BY、ORDER BY、DISTINCTの使用は避けてください。

理由:GROUP BY、ORDER BY、またはDISTINCTを使用すると、SQL Serverエンジンによってワークテーブルが作成され、データがワークテーブルに配置されます。 その後、クエリによって要求されたようにこのデータをワークテーブルに整理し、最終結果を返します。

Check Indexes

SQLステートメントのWHEREおよびJOIN部分で使用されるすべてのフィールドにインデックスがある必要があります。

理由:フィールドにインデックスが作成されていない場合、SQL Serverは通常、テーブル全体のスキャンを実行し、パフォーマンスが低下する可能性があります。 テーブルが非常に小さい場合を除き、テーブルスキャンはすべてのタイプのデータベース読み取りの中で最悪のパフォーマンスをもたらす傾向があります。

JOIN句とWHERE句で同じデータ型を使用する

これは、スキーマを変更するための権限に応じて行うよりも簡単です。

理由:異なるデータ型を持つ二つのフィールドを結合または比較する場合、SQLはフィールドにインデックスが付けられていても、比較を行う前にフィールドのオンザフライ変換を行う必要があります。 不一致のデータ型が避けられない場合は、可能な限り大きいデータ型を小さいデータ型にキャストしてください。

JOINおよびWHERE句での計算フィールドの使用を避ける

これは、テーブルの結合で使用される計算値を持つフィールドを作成することによって行うことがで 以下を参照。

Leave a Reply

メールアドレスが公開されることはありません。