1. where句で！=または<>演算子を使用しないようにしてください。使用しない場合、エンジンはインデックスの使用を中止し、全テーブルスキャンを実行します。
2.クエリを最適化するには、テーブル全体のスキャンをできるだけ回避する必要がありますまず、場所と順序に関係する列にインデックスを設定することを検討する必要があります。
3. where句のフィールドのnull値を判断しないようにしてください。そうしないと、エンジンがインデックスの使用をあきらめ、テーブル全体のスキャンを実行します。たとえば、
select id from t where num is null
は 、num にデフォルト値0を設定して、テーブルのnum列にnull値がない場合は、次のようにクエリし
ます。selectid from t where num = 0
4.またはwhere句を使用して条件を結合しないようにしてください。そうしないと、エンジンがインデックスの使用をあきらめて、フルテーブルスキャンを実行します。 ：
num = 10またはnum = 20の tからのselect idは、次の
ようにクエリできます：
select id from t where num = 10
union all
select id from t where num = 20
5.次のクエリでも、フルテーブルスキャンが行われます：（cannotパーセント記号を設定する）
'％abc％'のような名前のtからIDを選択
する効率を向上させるには、全文検索を検討できます。
6. inおよびnot inも注意して使用する必要があります。そうしないと、次のような全テーブルスキャンが発生し
ます。select id from t where num in（1,2,3）
連続値の場合は、inの代わりにbetweenを使用でき
ます。selectid from t where num between 1 and 3
7. where句でパラメーターを使用すると、テーブル全体がスキャンされます。SQLは実行時にローカル変数のみを解析するため、オプティマイザはアクセスプランの選択を実行時に延期することはできず、コンパイル時に選択する必要があります。ただし、アクセスプランがコンパイル時に確立される場合、変数の値はまだ不明であるため、インデックス選択の入力として使用できません。次のステートメントは、テーブル全体のスキャンを実行し
ます。selectid from t where [email = num = @ num] num = @ num [/ email]
を使用して、クエリで強制的にインデックスを使用
できます。selectid from t with（index（index name）） where [email = num = @ num] num = @ num [/ email]
8.エンジンがインデックスの使用を放棄して全表スキャンを実行する原因となるwhere句のフィールドで式演算を実行しないようにする必要があります。例：
select id from t where num / 2 = 100
は次のように変更する必要があり
ます ：select id from t where num = 100 * 2
9. where句のフィールドでの関数操作を回避しようとすると、代わりにエンジンがインデックスの使用を中止します。全表スキャンを実行します。例：
tからidを選択します。ここで、サブストリング（name、1,3）= 'abc'-id、名前はabcで始まります。
select id from t where datediff（day、createdate、 '2005-11-30'）= 0–'2005-11-30 'generated id
should be changed to：
select id from t where name like' abc％ '
select id from t where createdate> = '2005-11-30' and createdate <'2005-12-1'
10. where句の「=」の左側で関数、算術演算、またはその他の式演算を実行しないでください。そうしないと、システムが可能になりますインデックスは正しく使用できません。
11.インデックスフィールドを条件として使用する場合、インデックスが複合インデックスである場合、インデックスの最初のフィールドを条件として使用して、システムがインデックスを使用することを確認する必要があります。それ以外の場合、インデックスは使用されません。可能な限り、フィールドの順序をインデックスの順序と一致させます。
12.空のテーブル構造を生成する必要があるなど、意味のないクエリを記述しないでください
。tからcol1、col2を#tに選択します。ここで、1 = 0の
ようなコードは結果セットを返しませんが、システムリソースを消費するため、変更する必要があります。このようにし
て、テーブル#t（…）を作成します
13。
14.すべてのインデックスがクエリに有効であるとは限りません。SQLはテーブルのデータに基づいて最適化されます。インデックス列に大量のデータの重複がある場合、SQLクエリはインデックスを使用しない場合があります。たとえば、テーブルにsex、male、女性はほぼ半分であるため、インデックスが性別に基づいていても、クエリの効率には役立ちません。
15.インデックスが良いほど優れているわけではありません。対応する選択の効率は確実に向上しますが、同時に挿入または更新の効率も低下します。挿入または更新によりインデックスが再構築される可能性があるため、インデックスの構築方法には注意が必要です。特定の状況によって異なります。テーブルのインデックスの数は6を超えてはなりません。数が多すぎる場合は、頻繁に使用されない一部の列に構築されたインデックスが必要かどうかを検討する必要があります。
16.クラスター化インデックスデータ列の順序はテーブルレコードの物理的な格納順序であるため、クラスター化インデックスデータ列の更新はできるだけ避けてください。列の値が変更されると、テーブルレコード全体の順序が調整され、かなりのリソースが消費されます。アプリケーションシステムがクラスター化インデックスデータ列を頻繁に更新する必要がある場合は、インデックスをクラスター化インデックスとして構築する必要があるかどうかを検討する必要があります。
17.数値フィールドをできるだけ使用する数値情報のみを含むフィールドが文字型として設計されていない場合、これはクエリと接続のパフォーマンスを低下させ、ストレージのオーバーヘッドを増加させます。これは、クエリと接続を処理するときにエンジンが文字列内の各文字を1つずつ比較し、数値タイプの場合は1回だけ比較する必要があるためです。
18. char / ncharではなくvarchar / nvarcharをできるだけ使用します。これは、最初に可変長フィールドのストレージスペースが小さくなり、ストレージスペースを節約できるためです。次に、クエリの場合、比較的小さなフィールドでの検索効率が明らかに高くなります。
19. select * from tはどこでも使用しないでください。「*」を特定のフィールドリストに置き換え、使用されていないフィールドは返さないでください。
20.一時テーブルの代わりにテーブル変数を使用してみてください。テーブル変数に大量のデータが含まれている場合、インデックスは非常に制限されていることに注意してください（主キーインデックスのみ）。
21.一時テーブルの頻繁な作成と削除を避けて、システムテーブルリソースの消費を減らします。
22.一時テーブルは使用できないわけではありません。たとえば、大きなテーブルまたは頻繁に使用されるテーブルのデータセットを繰り返し参照する必要がある場合など、それらを適切に使用すると、一部のルーチンがより効果的になります。ただし、1回限りのイベントの場合は、エクスポートテーブルを使用することをお勧めします。
23.一時テーブルを作成するときに、大量のデータを一度に挿入する場合は、テーブルを作成する代わりにselect intoを使用して、速度を向上させるために多数のログを回避できます。データ量が大きくない場合は、システムテーブルのリソースを緩和するために、最初にテーブルを作成してから挿入します。
24.一時テーブルを使用する場合、システムテーブルの長期ロックを回避するために、ストアドプロシージャの最後にすべての一時テーブルを明示的に削除し、最初にテーブルを切り捨ててからテーブルを削除する必要があります。
25.カーソルはできるだけ使用しないでください。カーソルの効率が悪いため、カーソル操作のデータが10,000行を超える場合は、書き換えを検討してください。
26.カーソルベースの方法または一時テーブルの方法を使用する前に、まず問題を解決するためのセットベースのソリューションを探す必要があります。通常、セットベースの方法の方が効果的です。
27.一時テーブルと同様に、カーソルは使用できません。必要なデータを取得するために複数のテーブルを参照する必要がある場合は特に、小さいデータセットに対してFAST_FORWARDカーソルを使用することは、通常、他の行ごとの処理方法よりも優れています。結果セットに「合計」を含むルーチンは、通常、カーソルを使用するよりも速く実行されます。開発時間が許せば、カーソルベースの方法とセットベースの方法の両方を試して、どちらの方法が優れているかを確認できます。
28.すべてのストアドプロシージャとトリガーの最初にSET NOCOUNT ONを設定し、最後にSET NOCOUNT OFFを設定します。ストアドプロシージャとトリガーの各ステートメントを実行した後、DONE_IN_PROCメッセージをクライアントに送信する必要はありません。
29.クライアントに大量のデータを返さないようにしてくださいデータの量が多すぎる場合は、対応する要件が妥当かどうかを検討する必要があります。
30.大規模なトランザクション操作を回避し、システムの同時実行性を改善するようにしてください。
2.クエリを最適化するには、テーブル全体のスキャンをできるだけ回避する必要がありますまず、場所と順序に関係する列にインデックスを設定することを検討する必要があります。
3. where句のフィールドのnull値を判断しないようにしてください。そうしないと、エンジンがインデックスの使用をあきらめ、テーブル全体のスキャンを実行します。たとえば、
select id from t where num is null
は 、num にデフォルト値0を設定して、テーブルのnum列にnull値がない場合は、次のようにクエリし
ます。selectid from t where num = 0
4.またはwhere句を使用して条件を結合しないようにしてください。そうしないと、エンジンがインデックスの使用をあきらめて、フルテーブルスキャンを実行します。 ：
num = 10またはnum = 20の tからのselect idは、次の
ようにクエリできます：
select id from t where num = 10
union all
select id from t where num = 20
5.次のクエリでも、フルテーブルスキャンが行われます：（cannotパーセント記号を設定する）
'％abc％'のような名前のtからIDを選択
する効率を向上させるには、全文検索を検討できます。
6. inおよびnot inも注意して使用する必要があります。そうしないと、次のような全テーブルスキャンが発生し
ます。select id from t where num in（1,2,3）
連続値の場合は、inの代わりにbetweenを使用でき
ます。selectid from t where num between 1 and 3
7. where句でパラメーターを使用すると、テーブル全体がスキャンされます。SQLは実行時にローカル変数のみを解析するため、オプティマイザはアクセスプランの選択を実行時に延期することはできず、コンパイル時に選択する必要があります。ただし、アクセスプランがコンパイル時に確立される場合、変数の値はまだ不明であるため、インデックス選択の入力として使用できません。次のステートメントは、テーブル全体のスキャンを実行し
ます。selectid from t where [email = num = @ num] num = @ num [/ email]
を使用して、クエリで強制的にインデックスを使用
できます。selectid from t with（index（index name）） where [email = num = @ num] num = @ num [/ email]
8.エンジンがインデックスの使用を放棄して全表スキャンを実行する原因となるwhere句のフィールドで式演算を実行しないようにする必要があります。例：
select id from t where num / 2 = 100
は次のように変更する必要があり
ます ：select id from t where num = 100 * 2
9. where句のフィールドでの関数操作を回避しようとすると、代わりにエンジンがインデックスの使用を中止します。全表スキャンを実行します。例：
tからidを選択します。ここで、サブストリング（name、1,3）= 'abc'-id、名前はabcで始まります。
select id from t where datediff（day、createdate、 '2005-11-30'）= 0–'2005-11-30 'generated id
should be changed to：
select id from t where name like' abc％ '
select id from t where createdate> = '2005-11-30' and createdate <'2005-12-1'
10. where句の「=」の左側で関数、算術演算、またはその他の式演算を実行しないでください。そうしないと、システムが可能になりますインデックスは正しく使用できません。
11.インデックスフィールドを条件として使用する場合、インデックスが複合インデックスである場合、インデックスの最初のフィールドを条件として使用して、システムがインデックスを使用することを確認する必要があります。それ以外の場合、インデックスは使用されません。可能な限り、フィールドの順序をインデックスの順序と一致させます。
12.空のテーブル構造を生成する必要があるなど、意味のないクエリを記述しないでください
。tからcol1、col2を#tに選択します。ここで、1 = 0の
ようなコードは結果セットを返しませんが、システムリソースを消費するため、変更する必要があります。このようにし
て、テーブル#t（…）を作成します
13。
14.すべてのインデックスがクエリに有効であるとは限りません。SQLはテーブルのデータに基づいて最適化されます。インデックス列に大量のデータの重複がある場合、SQLクエリはインデックスを使用しない場合があります。たとえば、テーブルにsex、male、女性はほぼ半分であるため、インデックスが性別に基づいていても、クエリの効率には役立ちません。
15.インデックスが良いほど優れているわけではありません。対応する選択の効率は確実に向上しますが、同時に挿入または更新の効率も低下します。挿入または更新によりインデックスが再構築される可能性があるため、インデックスの構築方法には注意が必要です。特定の状況によって異なります。テーブルのインデックスの数は6を超えてはなりません。数が多すぎる場合は、頻繁に使用されない一部の列に構築されたインデックスが必要かどうかを検討する必要があります。
16.クラスター化インデックスデータ列の順序はテーブルレコードの物理的な格納順序であるため、クラスター化インデックスデータ列の更新はできるだけ避けてください。列の値が変更されると、テーブルレコード全体の順序が調整され、かなりのリソースが消費されます。アプリケーションシステムがクラスター化インデックスデータ列を頻繁に更新する必要がある場合は、インデックスをクラスター化インデックスとして構築する必要があるかどうかを検討する必要があります。
17.数値フィールドをできるだけ使用する数値情報のみを含むフィールドが文字型として設計されていない場合、これはクエリと接続のパフォーマンスを低下させ、ストレージのオーバーヘッドを増加させます。これは、クエリと接続を処理するときにエンジンが文字列内の各文字を1つずつ比較し、数値タイプの場合は1回だけ比較する必要があるためです。
18. char / ncharではなくvarchar / nvarcharをできるだけ使用します。これは、最初に可変長フィールドのストレージスペースが小さくなり、ストレージスペースを節約できるためです。次に、クエリの場合、比較的小さなフィールドでの検索効率が明らかに高くなります。
19. select * from tはどこでも使用しないでください。「*」を特定のフィールドリストに置き換え、使用されていないフィールドは返さないでください。
20.一時テーブルの代わりにテーブル変数を使用してみてください。テーブル変数に大量のデータが含まれている場合、インデックスは非常に制限されていることに注意してください（主キーインデックスのみ）。
21.一時テーブルの頻繁な作成と削除を避けて、システムテーブルリソースの消費を減らします。
22.一時テーブルは使用できないわけではありません。たとえば、大きなテーブルまたは頻繁に使用されるテーブルのデータセットを繰り返し参照する必要がある場合など、それらを適切に使用すると、一部のルーチンがより効果的になります。ただし、1回限りのイベントの場合は、エクスポートテーブルを使用することをお勧めします。
23.一時テーブルを作成するときに、大量のデータを一度に挿入する場合は、テーブルを作成する代わりにselect intoを使用して、速度を向上させるために多数のログを回避できます。データ量が大きくない場合は、システムテーブルのリソースを緩和するために、最初にテーブルを作成してから挿入します。
24.一時テーブルを使用する場合、システムテーブルの長期ロックを回避するために、ストアドプロシージャの最後にすべての一時テーブルを明示的に削除し、最初にテーブルを切り捨ててからテーブルを削除する必要があります。
25.カーソルはできるだけ使用しないでください。カーソルの効率が悪いため、カーソル操作のデータが10,000行を超える場合は、書き換えを検討してください。
26.カーソルベースの方法または一時テーブルの方法を使用する前に、まず問題を解決するためのセットベースのソリューションを探す必要があります。通常、セットベースの方法の方が効果的です。
27.一時テーブルと同様に、カーソルは使用できません。必要なデータを取得するために複数のテーブルを参照する必要がある場合は特に、小さいデータセットに対してFAST_FORWARDカーソルを使用することは、通常、他の行ごとの処理方法よりも優れています。結果セットに「合計」を含むルーチンは、通常、カーソルを使用するよりも速く実行されます。開発時間が許せば、カーソルベースの方法とセットベースの方法の両方を試して、どちらの方法が優れているかを確認できます。
28.すべてのストアドプロシージャとトリガーの最初にSET NOCOUNT ONを設定し、最後にSET NOCOUNT OFFを設定します。ストアドプロシージャとトリガーの各ステートメントを実行した後、DONE_IN_PROCメッセージをクライアントに送信する必要はありません。
29.クライアントに大量のデータを返さないようにしてくださいデータの量が多すぎる場合は、対応する要件が妥当かどうかを検討する必要があります。
30.大規模なトランザクション操作を回避し、システムの同時実行性を改善するようにしてください。
