SQL ステートメントの最適化の原則、SQL ステートメントの最適化_PHP チュートリアル

SQL ステートメント最適化の原則、SQL ステートメントの最適化

100万レベルを超えるデータを処理することでクエリ速度を向上させる方法:

1。where 句では != または <> 演算子を使用しないようにしてください。使用しないと、エンジンはインデックスの使用を放棄し、テーブル全体のスキャンを実行します。

2。クエリを最適化するには、まず、where と order by に関係する列にインデックスを作成することを検討する必要があります。

3 where 句のフィールドで null 値の判断を行わないようにする必要があります。そうしないと、エンジンはインデックスの使用を放棄し、テーブル全体のスキャンを実行します。

例:

select id from t where num is null
num にデフォルト値 0 を設定し、テーブルの num 列に null 値がないことを確認してから、次のようにクエリを実行できます。
select id from t where num=
0

4 条件を接続するために where 句で または を使用することは避けてください。そうしないと、エンジンがインデックスの使用を断念し、完全な実行が行われます。テーブルスキャン (例: select id from t where num=
10 または num=20) 次のようにクエリできます:
select id from t where num=
10 Union all
Select id from t where num=
20

5 次のクエリも完全なテーブル スキャンになります: (パーセント記号の前に置くことはできません) Select id from t where '%abc%' のような名前です
効率を向上させるために、全文検索を検討できます。


6.in と not in も注意して使用する必要があります。そうしないと、次のような完全なテーブル スキャンが発生します。 select id from t where num in(
1,2) ,3)值 連続値の場合、次の場合は BetWeen を使用しないでください:
SELECT Id from T WHERE NUM BETWEEN select xx、電話 FROM send a JOIN (
select '13891030091' 電話 Union select '13992085916' ………… UNION SELECT '13619100234' ) b on a.Phone=b.phone

--大量のデータが分離されている場合は以下を置き換えてください

in('13891030091','13992085916','13619100234'…………)

7。where 句でパラメータが使用されている場合、テーブル全体のスキャンも発生します。 SQL は実行時にのみローカル変数を解決するため、オプティマイザは実行時までアクセス プランの選択を延期できません。選択はコンパイル時に行う必要があります。ただし、アクセス プランがコンパイル時に構築される場合、変数の値はまだ不明であり、インデックス選択の入力として使用できません。たとえば、次のステートメントは完全なテーブル スキャンを実行します:
Select id from t where num=@num これを変更して、クエリでインデックスを使用するように強制できます:
select id from t with (index (index name)) where num=@num

8。where 句内のフィールドに対する式操作は避けるようにしてください。これにより、エンジンがインデックスの使用を断念し、テーブル全体のスキャンが実行されます。例: c Select ID from T WHERE NUM/2
= 100 を次のように変更する必要があります:
Select ID from T WHERE NUM = 100
*2
9
9 . where 句内のフィールドに対して関数演算を実行すると、エンジンがインデックスの使用を断念し、テーブル全体のスキャンが実行されることになるので、回避する必要があります。例: select id from t where substring(name,
1,3)='abc' – abc で始まる名前 ID select id from t where datediff(day,createdate,'
2005) -11-30′)=0–'2005-11-30′ 生成された ID を次のように変更する必要があります:
select id from t where name like ' abc%'
createdate>='
2005-11-30' および createddate<'2005-12-1' から ID を選択します 10 .where 句の「=」の左側で関数、算術演算、その他の式演算を実行しないでください。実行しないと、システムがインデックスを正しく使用できない可能性があります。

11。インデックス フィールドを条件として使用する場合、インデックスが複合インデックスの場合、インデックスの最初のフィールドを条件として使用して、システムがインデックスを使用するようにする必要があります。そうでない場合は、インデックスが使用されます。は使用されず、フィールドの順序はインデックスの順序とできる限り一致する必要があります。

12 たとえば、空のテーブル構造を生成する必要がある場合:

selectcol1,col2 into #t where 1=
。 このタイプのコードは結果セットを返しませんが、システム リソースを消費します: create table #t(…)

13 に変更する必要があります。 in の代わりに存在するのが良い選択です:

select num from a where num in (select num from b) 次のステートメントに置き換えます:
select num from a where names (select 1
from b) SQL は、テーブル内のデータに基づいてクエリを最適化します。たとえば、テーブルに性別フィールドがあり、男性と女性がそれぞれほぼ半分であるため、インデックスが性別に基づいて構築されたとしても、クエリの効率には影響しません。
15。インデックスは、対応する選択の効率を向上させることができますが、挿入または更新中に再構築される可能性があるため、挿入と更新の効率も低下します。 ? インデックス作成には慎重な検討が必要であり、状況によって異なります。テーブルに 6 つを超えるインデックスを持たないことをお勧めします。多すぎる場合は、一般的に使用されない一部の列にインデックスを構築する必要があるかどうかを検討する必要があります。

16。クラスター化インデックス データ列の順序は、テーブル レコードの物理的な格納順序であるため、列の値が変更されると、その列の順序が調整されます。テーブル全体の記録には多額の費用がかかります。アプリケーション システムがクラスター化インデックスのデータ列を頻繁に更新する必要がある場合は、インデックスをクラスター化インデックスとして構築する必要があるかどうかを検討する必要があります。

17。数値情報のみを含むフィールドの場合は、クエリと接続のパフォーマンスが低下し、ストレージのオーバーヘッドが増加するように設計しないでください。これは、エンジンがクエリや接続を処理するときに文字列内の各文字を 1 つずつ比較し、数値型の場合は 1 回の比較だけで十分であるためです。

18。まず、可変長フィールドの記憶域スペースが小さく、クエリの検索効率を比較的高めることができるため、できるだけ char/nvarchar の代わりに varchar/nvarchar を使用してください。小さなフィールド 明らかに高いです。

19。どこでも select * from t を使用せず、「*」を特定のフィールド リストに置き換え、未使用のフィールドを返さないでください。

20。一時テーブルの代わりにテーブル変数を使用してみてください。テーブル変数に大量のデータが含まれている場合は、インデックスが非常に制限される (主キー インデックスのみ) ことに注意してください。

21。システム テーブル リソースの消費を減らすために、一時テーブルを頻繁に作成および削除しないようにします。

22 一時テーブルは使用できないわけではありません。一時テーブルを適切に使用すると、たとえば、大きなテーブルやよく使用されるテーブル内の特定のデータ セットを繰り返し参照する必要がある場合に、特定のルーチンをより効率的に実行できます。ただし、1 回限りのイベントの場合は、エクスポート テーブルを使用することをお勧めします。

23 一時テーブルを作成するときに、一度に挿入されるデータの量が多い場合は、create table の代わりに select into を使用すると、大量のログが発生して速度が向上するのを避けることができます。システムを容易にするために、データの量は大きくありません。テーブル リソースの場合は、最初にテーブルを作成してから挿入する必要があります。

24。一時テーブルを使用する場合は、ストアド プロシージャの最後にすべての一時テーブルを明示的に削除する必要があります。これにより、システム テーブルの長期ロックを回避できます。

25。カーソルによって操作されるデータが 10,000 行を超える場合は、カーソルの使用を避けるようにしてください。

26。カーソルベースの方法または一時テーブル方法を使用する前に、まずセットベースの方法で問題を解決する必要があります。通常、セットベースの方法の方が効果的です。

27。一時テーブルと同様に、カーソルは使用できないわけではありません。小規模なデータ セットに FAST_FORWARD カーソルを使用することは、特に必要なデータを取得するために複数のテーブルを参照する必要がある場合、他の行ごとの処理方法よりも優れていることがよくあります。結果セットに「合計」を含むルーチンは、通常、カーソルを使用するよりも高速です。開発時間が許せば、カーソルベースの方法とセットベースの方法の両方を試して、どちらの方法がより効果的に機能するかを確認できます。

28。すべてのストアド プロシージャとトリガーの最初に SET NOCOUNT ON を設定し、最後に SET NOCOUNT OFF を設定します。ストアド プロシージャとトリガーの各ステートメントの後に DONE_IN_PROC メッセージをクライアントに送信する必要はありません。

29。大量のデータをクライアントに返さないようにしてください。データの量が大きすぎる場合は、対応する要件が妥当であるかどうかを検討する必要があります。

30。大規模なトランザクション操作を避け、システムの同時実行性を向上させてください。

記事の出典: http://www.cnblogs.com/pepcod/archive/2013/01/01/2913496.html

SQL の最適化に関する記事リファレンス:

http://www.cnblogs.com/ATree/archive/2011/02/13/sql_optimize_1.html

http://blog.csdn.net/csh624366188/article/details/8457749

http://www.iteye.com/problems/100945 http：//blog.itpub.net/28389881/viewspace-1301549/が最適化されています

http://www.bkjia.com/PHPjc/1033985.htmlwww.bkjia.com本当http://www.bkjia.com/PHPjc/1033985.html技術記事 SQL ステートメントの最適化の原則、100 万レベルを超えるデータを処理するための SQL ステートメントの最適化によってクエリ速度を向上させる方法: 1. where 句で != または演算子を使用しないようにしてください。そうしないと、エンジンが諦めます...