前置き
SQLの実行する前に、「どのようにプロセスが実行され、どのようを改善したら素早いクエリが実行できるのか？を図形的に捉えることは重要なことです。
策もなしに、SQLを雑に描いていては、素早く実行できるものも、遅くなってしまいます。
そこで今回は、ECRS原則を用いた、SQLチューニングについて触れていきます。
ECRSについて簡単におさらい
この原則については、過去にいろいろ記事を書いてるのでそちらを参考にしてください。
ECRS原則は、もともと製造業の業務改善（カイゼン）で使われる考え方ですが、SQLのクエリチューニングに応用するのは、非常に的確で効果的なアプローチです。
JOIN句は、テーブルのデータを一度メモリ上に展開し、結合条件に基づいてレコードを照合するという、本質的にコストの高い操作です。
そのため、ボトルネックに割かしなりやすい部分ではあります。
ECRSのフレームワークは、このコストの高いJOIN操作を、体系的に見直すための優れた思考ツールとなります。
Eliminate (なくせないか？ - 排除)
「そもそも、このJOINは本当に必要か？」
を問います。JOIN句自体をなくせれば、効果は絶大です。
非正規化
最も強力な手法です。
ordersテーブルを検索する際に、顧客名を表示するために毎回customersテーブルをJOINしているのであれば、あらかじめordersテーブルにcustomer_nameカラムを追加・保存しておくことで、JOINそのものを排除します。
ただし、データの冗長性とのトレードオフになる。
これにより、読み取り時のJOINは不要になりますが、代わりに書き込み（INSERT/UPDATE）時に、以下のように両方のデータを同期させる余分な処理が必要になります。
※データの不整合リスクが上がるので、私はほぼこの手法は好みません。
不要なJOINの削除
クエリをコピー＆ペーストするうちに、SELECT句では使われていないのに、JOIN句だけが残っているケースがあります。
このような不要なJOINは、単純に削除します。
Combine (一緒にできないか？ - 結合)
「複数の処理を、より少ない処理にまとめられないか？」
を問います。
クエリの統合
アプリケーションが、ループ内で何度も個別のクエリを発行しているのであれば、それらをUNION ALLやCASE文を使って、単一のクエリにまとめることで、データベースへのラウンドトリップ（往復回数）を減らします。
マテリアライズド・ビュー（実体化ビュー）
頻繁にJOINされるテーブル群を、あらかじめJOINした結果として、物理的なテーブル（マテリアライズド・ビュー）として保持しておきます。
クエリは、この事前に結合済みの単一テーブルを参照するだけで済みます。
詳細
特に分析系のクエリで、毎回同じ複雑なJOINや集計を繰り返している場合に有効です。
その重いクエリの結果を、あらかじめ物理的な実体を持つマテリアライズド・ビューとして保存しておく。
すると利用者は、その軽量な結果テーブルを叩くだけで済むようになります。
※トレードオフは、データの鮮度です。
ビューは定期的にリフレッシュする必要があり、リアルタイムのデータは反映されません。
具体例
日次の売上集計レポートのために、毎回重い集計クエリを実行している場合。
Rearrange (順序を変えられないか？ - 交換)
「処理の順序を入れ替えて、効率化できないか？」
を問います。
先にフィルタ、後でJOIN
巨大なテーブル同士をJOINする前に、WHERE句やサブクエリ、CTE（共通テーブル式） を使って、各テーブルをできるだけ小さなサイズに絞り込んでからJOINします。
これにより、JOINが処理すべきレコード数が劇的に減り、パフォーマンスが向上します。
詳細
巨大なテーブル同士をJOINする場合、
JOINする前にWHERE句で可能な限りレコードを絞り込む
ことが鉄則です。
これにより、JOINアルゴリズムが処理しなければならないデータ量が劇的に減ります。
現代の多くのクエリオプティマイザは自動でこれを行いますが、サブクエリやCTE（共通テーブル式）を使って明示的に順序を指示することで、より確実な性能向上が期待できます。
具体例
東京都の顧客の注文履歴を検索する場合。
Simplify (もっと単純にできないか？ - 単純化)
「処理をもっとシンプルな方法で実現できないか？」
を問います。
上記のEやCが実行できそうにない時には、ココから始めてしまっても何ら問題ないです。
インデックスの活用
JOINするカラムや、WHERE句で頻繁に使うカラムに適切なインデックスを作成します。
これにより、テーブルのフルスキャンという最も重い処理が、高速なインデックス検索に置き換わります。
WHERE句の関数使用を避ける
WHERE YEAR(order_date) = 2025
のような書き方は、order_dateのインデックスが使えなくなる原因です。
WHERE order_date >= '2025-01-01' AND order_date < '2026-01-01'
のように、インデックスが有効になるシンプルな比較に書き換えます。
具体例
顧客コードの先頭2文字が'TK'の顧客を探すような場合。
存在確認にはEXISTSを使う
「テーブルAに存在するレコードのうち、テーブルBにも対応するレコードが存在するもの」を取得したい場合、JOINやIN句よりもWHERE EXISTS (...)を使った方が、高速になることがあります。
まとめ
このように、ECRSの原則を適用することで、場当たり的ではない、体系的なクエリの改善・リファクタリングが可能になります。
是非、いきなりSQL書くんでなく、一旦立ち止まり、モデルを描いて、ECRSを適用してみてから、コードを書いてみてください。