データベースを扱う上で避けて通れないのが「テーブル結合（JOIN）」です。SQLを書けば結果は同じですが、データベースの内部では「どうやって結合するか」というアルゴリズムの選択が、処理速度を100倍、1000倍と変えてしまいます。
今回は、情報処理技術者試験（データベーススペシャリスト）の頻出問題から、実務で役立つ現場のノウハウまでを一気に解説します。
1. 今日のクイズ：このアルゴリズムの名前は？
問題
データベースにおける2つの表の結合のうち、ソートを行ったのちマージを行う方法は、次のうちどれか？
(ア) 入れ子ループ法（Nested Loop Join）
(イ) ルールベース法
(ウ) コストベース法
(エ) ソートマージ法（Sort Merge Join）
正解： （エ）ソートマージ法
2. 主要な3つの結合アルゴリズム
試験や実務で登場する結合方法は、主に以下の3つです。それぞれに得意・不得意があります。
① 入れ子ループ法（Nested Loop Join）
プログラミングの「2重ループ」と同じ動きです。外側の表から1行取り出し、内側の表を全スキャンして一致を探します。
得意: 抽出結果が少量の場合。
ポイント: 内側の表の結合キーにインデックスがあれば爆速になります。
② ソートマージ法（Sort Merge Join）
今回の正解。結合キーで両方の表を事前にソートし、端から順にマージします。
得意: 大量データの結合。
ポイント: インデックスがなくても動作しますが、ソートのためのCPU負荷がかかります。
③ ハッシュ結合（Hash Join）
片方の表からメモリ上に「ハッシュテーブル」を作成し、もう片方の表と突き合わせます。
得意: 大量データ同士の等価結合。
ポイント: メモリ（ワークエリア）を大量に消費するため、不足するとディスクI/Oが発生して遅くなります。
3. 「データ量」がアルゴリズムを決める
なぜこれほど種類があるのか？ それは返すデータ量によって最適な方法が異なるからです。
| 結合方法 | 得意なデータ量 | インデックス | 備考 |
| Nested Loop | 1件〜少量 | 必須 | オンライン処理の基本 |
| Sort Merge | 大量 | あれば尚可 | 不等号結合（<, >）でも使える |
| Hash Join | 大量 | 不要 | 等価結合（＝）のみ。バッチ処理向け |
4. DBが「気に入らない動き」をした時の介入術
通常、DBは「統計情報」を元に自動で最適な計画を立てますが、稀に判断を誤ります。その際、エンジニアが介入する方法は製品ごとに異なります。
Oracle：ヒント句
SQL文に直接
/*+ USE_NL(a b) */と書き込み、「この方法でやれ」と強制します。非常に強力です。PostgreSQL：パラメータ制御
標準ではヒント句を使いません。
SET enable_mergejoin = off;のように、特定のアルゴリズムを無効化して、消去法で別の道を選ばせます。MySQL：インデックスヒント
USE INDEX (col_index)を指定して、特定のインデックスを使わせることで、間接的にアルゴリズムを誘導します。
5. 見習いエンジニアの考察
「SQLの結果が合っていればOK」というのは、まだ入り口。その裏側でDBが「ソートしようか、ハッシュを作ろうか」と悩んでいるプロセスを知ることで、初めて「重いクエリ」に対処できるようになります。
0 件のコメント:
コメントを投稿