MySQL でビッグ データのクエリを最適化するときに注意すべき点は何ですか?

mysql におけるビッグ データ クエリの最適化に関する注意事項: 1. クエリを最適化する場合、フル テーブル スキャンは可能な限り回避する必要があります; 2. where 句のフィールドの null 値判定は回避する必要があります; 3.および Not in も注意して使用する必要があります。4. 接続する where 句での または の使用は避けてください。5. カーソルの使用は避けてください。

mysql でビッグ データ クエリを最適化する方法:

1. クエリを最適化するときは、すべての For を避けるようにしてください。テーブル スキャンの場合は、まず where および order by に関係する列にインデックスを作成することを検討する必要があります。

2. where 句でフィールドの null 値を判断しないようにしてください。そうしないと、エンジンはインデックスの使用を断念し、次のような完全なテーブル スキャンを実行します: select id from t where num is null num に指定できます。デフォルト値 0 を設定し、テーブルの num 列に null 値がないことを確認してから、

select id from t where num=0

3 のようにクエリを実行します。!= または <> の使用は避けてください。 ; where 句に演算子を使用しない場合、エンジンはインデックスを使用したフル テーブル スキャンの実行を中止します。

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.in と not in も注意して使用する必要があります。そうしないと、次のようにテーブル全体のスキャンが行われることになります: select id from t where num in(1, 2,3) 連続値の場合、in の代わりに between を使用できます:

select id from t where num between 1 and 3

6。次のクエリも完全なテーブル スキャンになります: select id from t where name like '%李%' To効率を向上させるには、全文検索を検討してください。

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

select id from t with(index(索引名)) where num=@num

8。 where 句でのインデックスの使用は避けてください。フィールドは式操作を実行するため、エンジンはインデックスの使用を放棄し、テーブル全体のスキャンを実行します。例: select id from t where num/2=100 を次のように変更する必要があります: select id from t where num=100*2

9。回避 where 句内のフィールドに対して関数演算を実行すると、エンジンはインデックスの使用を断念し、テーブル全体のスキャンを実行します。例: select id from t where substring(name,1,3)='abc'、名前が abc で始まる ID は、

select id from t where name like ‘abc%’

10 に変更する必要があります。 where 句の「=」 関数、算術演算、またはその他の式演算を実行します。そうしないと、システムがインデックスを正しく使用できない可能性があります。

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

12. 意味のないクエリは作成しないでください。たとえば、空のテーブル構造を生成する必要がある場合:

select col1,col2 into #t from t where 1=0

このタイプのコードは結果セットを返しませんが、システムを消費します。次のように:

create table #t(…)

13. 多くの場合、in の代わりに存在を使用するのが良い選択です。

select num from a where num in(select num from b)

Use 次のステートメントを置き換えます:

select num from a where exists(select 1 from b where num=a.num)

14. すべてのインデックスがクエリに有効であるわけではありません。SQL はテーブル内のデータに基づいてクエリを最適化します。大量の重複データがある場合インデックス列では、SQL クエリはインデックスを使用できない可能性があります。たとえば、テーブルに性別フィールドがあり、ほぼ半数が男性、半数が女性である場合、インデックスが性別に基づいて構築されている場合でも、クエリ効率への影響。

15. インデックスは多ければ多いほど良いです。インデックスによって対応する選択の効率は向上しますが、挿入または更新中にインデックスが再構築される可能性があるため、挿入と更新の効率も低下します。 ? インデックス作成には慎重な検討が必要であり、状況によって異なります。 1 つのテーブルに 6 つを超えるインデックスを持たないことが最善ですが、多すぎる場合は、一般的に使用されない一部の列にインデックスを構築する必要があるかどうかを検討する必要があります。

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

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

18. char/nchar の代わりに varchar/nvarchar をできる限り使用してください。第一に、可変長フィールドの記憶領域が小さいため、節約できるからです。ストレージ スペース、そしてクエリ用です。とはいえ、比較的小さなフィールド内で検索する方が明らかに効率的です。

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

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

21. システム テーブル リソースの消費を減らすために、一時テーブルを頻繁に作成および削除することは避けてください。

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

23. 一時テーブルを作成するときに、一度に大量のデータが挿入される場合は、create table の代わりに select into を使用すると、問題の発生を避けることができます。高速化; データ量が多くない場合、システム テーブルのリソースを軽減するために、最初にテーブルを作成してから挿入する必要があります。

24. 一時テーブルを使用する場合は、ストアド プロシージャの最後ですべての一時テーブルを明示的に削除する必要があります (最初に truncate table、次に drop table)。そのため、システム テーブルの長時間のロックを回避できます。

25. カーソルは効率が悪いため、カーソルの使用は避けてください。カーソルで操作するデータが 10,000 行を超える場合は、データの書き換えを検討してください。

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

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

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

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

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

#その他の関連する無料学習の推奨事項: mysql チュートリアル(ビデオ)

以上がMySQL でビッグ データのクエリを最適化するときに注意すべき点は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。