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