破壊的なサブクエリ
よくあるSQLクエリの間違いに関するこのシリーズでは、最初の検査では完全に安定しているように見えるが、誤った結果やパフォーマンスの低下につながる可能性のあるSQLクエリの例をいくつか見てきました。先週、述語の配置がクエリの実行にどのように悪影響を与える可能性があるか - 特に外部結合で影響があるかを学びました。今日の記事では、サブクエリと、サブクエリがその基になるテーブルに変更が加えられた時にどのようにSQLステートメントを破壊するかに焦点を当てます。
外部結合とデカルト積
よくあるSQLクエリの間違いに関するこのシリーズでは、SQLクエリを構築する一見直感的な方法が誤った結果やパフォーマンスの低下につながるアンチパターンをもたらす可能性があることを調査してきました。先週、SQLの述語について話すためにこのシリーズをお休みしました。今回の記事では、それらの配置がクエリの実行にどのように悪い影響を与える可能性があるか、特に外部結合でどのように影響するかを学習します。
パート2: 非SARGableクエリの条件
ほとんどのプログラマーと同様に、データベース開発者は、多かれ少なかれ特定の要求の直接変換であるコードを作成する傾向があります。ほとんどのプログラミング言語(SQLを含む)が人間が読めるように設計されているという事実も、この問題の原因です。なぜこれが懸念事項なのですか?全てのプログラミング言語は、特定の操作を他よりも高速に実行します。リレーショナルデータベースでは、クエリオプティマイザがSQLクエリを分析し、クエリプランと呼ばれる効率的な実行メカニズムを決定します。オプティマイザは、クエリごとに1つ以上のクエリプランを生成します。各プランは、クエリを実行するための1つの可能な方法を示します。最も効率的なクエリプランがその後選択され、クエリの実行に利用されます。結局のところ、リクエストの言語を模倣するSQLが最も効率的なアプローチになることはめったにありません。
よくあるSQLクエリの間違いシリーズの今回の記事では、不十分に記述されたSQLステートメントの1つの例を調査し、効率を高める方法でそれを書き直します。
NOT IN 対 NOT EXISTS
「アンチパターン」と呼ばれるプログラミングサークルで一般的に使用される用語があります。これは、効果がないだけでなく、非常に逆効果になるリスクがある、繰り返し発生する問題への対応を指します。この用語は、1995年にコンピュータープログラマーのAndrew Koenigが著書『Design Patterns』で、信頼性と効果の両方を備えていると考えられているデザインパターンの反対として造られました。