SQLパフォーマンスの最適化

前書き: 今日は、より重要な問題である SQL パフォーマンスの最適化について紹介します。

データベースを運用する際に SQL ステートメントをいかに効率的にするかは非常に重要な問題です。以下にパフォーマンスの最適化に関する問題をまとめます。

SQL パフォーマンスの最適化

1. SELECT ステートメントではフィールド名を指定する必要があります

SELECT * は大幅に増加します不要な消費、(CPU、IO、メモリ、ネットワーク帯域幅); カバーインデックスを使用する可能性が高まります;

テーブル構造が変更されると、前のブレークも更新する必要があります。したがって、選択後にフィールド名を直接追加する必要があります。

2. SQL ステートメントの IN に含まれる値は多すぎてはいけません

MySQL は IN に対応する最適化を行っています。つまり、IN のすべての定数は配列に格納されます。そしてこの配列は順番にあります。

ただし、値が大きい場合、消費量は比較的多くなります。連続値の場合、 between を使用できる場合は in を使用しないでください。または、代わりに connection を使用してください。

3. inとexists、not inとnotexsを区別する

select * from 表A 
where id in (select id from 表B)

は

select * from 表A 
where exists(select * from 表B where 表B.id=表A.id)

と同等ですinとexistsの区別は主に次のとおりです。ドライバによって順序が変わります (これがパフォーマンス変化の鍵です) 存在する場合は外部テーブルが駆動テーブルとなり、最初にアクセスされます。 IN の場合はサブクエリが最初に実行されます。

つまり、IN は外面が大きく内部テーブルが小さい状況に適しており、EXISTS は外面は小さいが内部テーブルが大きい状況に適しています。

4. % プレフィックス ファジー クエリの使用は推奨されません。

たとえば、LIKE “%name” や LIKE “%name%” など、この種のクエリは使用できません。フルテーブルスキャン。ただし、LIKE "name%" は使用できます。

暗黙的な型変換を避ける:

where 句の列フィールドの型が、渡されたパラメーターの型と一致しない場合に発生する型変換。最初に where

5 のパラメータ タイプを決定することをお勧めします。ジョイント インデックスの場合、左端のプレフィックス ルールに従う必要があります。

たとえば、インデックスにはフィールド ID が含まれます。 、名前、学校、id フィールドを直接使用することも、id、名前の順序で使用することもできますが、学校はこのインデックスを使用できません。

したがって、結合インデックスを作成するときは、インデックス フィールドの順序に注意し、よく使用されるクエリ フィールドを最初に配置する必要があります。

上記の提案を要約すると、次のようになります。

1. インデックス フィールドでの計算操作を避ける

2. not <> != の使用を避ける

3. インデックスで is null、is not null の使用を避けるフィールド

3. インデックス フィールドでのデータ型変換を避ける

4. インデックス フィールドでの関数の使用を避ける

5. インデックス付き列での null 値の使用を避ける

6. WHERE のステートメント規則

7. WHERE 句で in、not in、または have in を使用することは避けてください。in、not in の代わりに、exist、notexist を使用できます。

8. 数値を文字形式で宣言しないでください。文字値を数値形式で宣言しないでください。そうしないとインデックスが無効になります。

上記は、すべての人に向けていくつかの問題をまとめたものです。その他の質問については、こちらをご覧ください。 PHP 中国語 Web サイトの対応するチュートリアル :https://www.php.cn/course/list/51/type/2.html

以上がSQLパフォーマンスの最適化の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。