この記事では、SQL のパフォーマンスを最適化および向上させるための方法を紹介します。一定の参考値があります。必要な友人は参照してください。お役に立てば幸いです。
Ø 単純なパフォーマンスの最適化
SQL パフォーマンスの最適化は、データベース エンジニアが実際の業務で直面しなければならない重要なトピックの 1 つです。一部のデータベース エンジニアにとって、これがほぼ唯一の提案です。実際、WEBサービスのような高速なレスポンスが求められるアプリケーションでは、SQLの性能がシステムを利用できるかどうかを直接左右します。ここでは主に、SQL を使用して実行を高速化し、メモリ消費量を削減する最適化手法をいくつか紹介します。今日の記事ではその 1 つだけを紹介します。今後、他の最適化手法も更新していきます。
クエリのパフォーマンスを厳密に最適化する場合は、使用するデータベースの機能特性を理解する必要があります。さらに、クエリ速度が遅いのは SQL ステートメント自体だけが原因ではなく、メモリ割り当てが不十分であること、ファイル構造が不合理であること、その他の理由によっても発生します。したがって、ここで紹介する SQL の最適化方法ですべてのパフォーマンスの問題が解決されるわけではありませんが、クエリのパフォーマンスが低下する原因の多くが SQL の無理な書き方であることは事実です。
Ø 効率的なクエリを使用する
SQL では、異なるコードで同じ結果が得られることがよくあります。理論的には、同じ結果を生成する異なるコードは同じパフォーマンスを持つはずですが、残念ながら、クエリ オプティマイザーによって生成される実行プランは、コードの外部構造に大きく影響されます。したがって、クエリのパフォーマンスを最適化したい場合は、オプティマイザーをより効率的に実行するためのコードの記述方法を知っておく必要があります。
パラメータがサブクエリの場合、IN
IN述語の代わりにEXISTSを使うと非常に便利で、コードもわかりやすいのでよく使われます。ただし、IN 述語は便利である一方で、パフォーマンスの最適化においてボトルネックになる危険性があります。コードで多くの IN 述語が使用されている場合、通常はそれらを最適化するだけでパフォーマンスが大幅に向上します。
IN のパラメータが「1、2、3」などの数値リストの場合、通常は特別な注意は必要ありません。ただし、パラメータがサブクエリの場合は注意が必要です。
ほとんどの場合、[NOT]IN と [NOT]EXISTS によって返される結果は同じです。ただし、両方をサブクエリに使用すると、EXISTS の方が高速になります。
例を見てみましょう:
Class_A テーブルから、Class_B テーブルにも存在する従業員を見つけようとします。次の 2 つの SQL ステートメントは同じ結果を返しますが、EXISTS を使用した SQL ステートメントの方が高速です。
両方の結果は次のとおりです:
EXISTS を使用すると高速になる理由は 2 つあります。
a) 接続列 (id) にインデックスが確立されている場合、Class_B をクエリするときに実際のテーブルをクエリする必要はなく、インデックスのみをクエリする必要があります。
b) EXISTS を使用した場合、データ行が条件を満たす限りクエリは終了し、IN を使用した場合のようにテーブル全体をスキャンする必要はありません。この時点では NOT EXISTS についても同様です。
IN のパラメータがサブクエリの場合、データベースは最初にサブクエリを実行し、次に結果を一時作業テーブル (インライン ビュー) に保存してから、ビュー全体をスキャンします。多くの場合、このアプローチは非常にリソースを大量に消費します。 EXISTS を使用すると、データベースは一時作業テーブルを生成しません。
ただし、コードの読みやすさの観点からは、EXISTS よりも IN の方が優れています。 IN を使用すると、コードがより明確になり理解しやすくなります。したがって、IN を使用するとすぐに結果が得られることが確実な場合は、EXISTS に変更する必要はありません。
さらに、最近では多くのデータベースが IN のパフォーマンスの向上に努めています。おそらく将来、IN がどのデータベース上にあっても EXISTS と同じパフォーマンスを達成できるようになるかもしれません。
パラメータがサブクエリの場合は、IN の代わりに接続を使用します。
IN のパフォーマンスを向上させるには、EXISTS の使用に加えて、接続を使用することもできます。前のクエリ ステートメントは、次のように「フラット化」できます。
この記述方法では、少なくともテーブルの "id" 列のインデックスを使用できます。さらに、サブクエリがないため、データベースは中間テーブルを生成しません。 EXISTS よりもどちらが優れているかを言うのは難しいですが、インデックスがない場合は、結合よりも EXISTS の方がわずかに優れている可能性があります。また、多くのクエリから、場合によっては接続を使用するよりも EXISTS を使用する方が適切であることがわかります。
以上がSQL パフォーマンスを最適化および改善する方法の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。