基本情報 平成26年度 秋期 問25：テクノロジ系に関する問題

答えは a「オプティマイザ」 です。

「オプティマイザ（optimizer）」はSQLを実行する最適な方法を自動で選ぶ仕組み。

例えば「この検索ならインデックスを使った方が速い」「あの結合は順番を変えた方が速い」とRDBMSが裏で頭脳的に判断してくれます。

👉 覚え方：「オプティマイズ＝最適化。クエリの実行プランを最適化する人」。

ほかの選択肢：b ガベージコレクション（メモリ解放）／c クラスタリング（複数サーバ）／d 文字化け。どれもオプティマイザではない。

なぜこれが正解か

正解は a「オプティマイザ」。オプティマイザ（Query Optimizer、問合せ最適化部）はRDBMSのコンポーネントで、SQL文を解析し統計情報（テーブルサイズ、インデックス、データ分布のヒストグラム等）に基づいて最も効率的な実行計画（execution plan）を選択する。同じSQL文でも複数の実行方法（インデックス使用/フルスキャン、結合順序、結合アルゴリズム等）があり、オプティマイザがコストを見積もって最適なものを選ぶ。

各選択肢の解説

• a オプティマイザ：SQL最適化の機能（正解）。
• b ガベージコレクション：プログラミング言語処理系でメモリ自動解放、DBには直接関係なし。
• c クラスタリング：複数サーバを束ねて1つのシステムに見せる技術、HAやスケーラビリティ用。
• d 文字化けで判定不能。

覚え方・ひっかけ注意

「オプティマイザ＝SQL最適化エンジン」。実行計画は`EXPLAIN`/`EXPLAIN ANALYZE`で確認可能。オプティマイザの方式:

• ルールベースオプティマイザ（RBO）: ヒューリスティック規則で決定。古い方式
• コストベースオプティマイザ（CBO）: 統計情報に基づきコスト計算、現代の主流

統計情報が古いとオプティマイザの判断が外れるため、定期的な`ANALYZE`/`UPDATE STATISTICS`が必要。

理論的背景

RDBMSのクエリ処理は一般に以下のフェーズで進行:

1. 構文解析（Parser）: SQLを構文木（AST）に変換

2. 意味解析（Analyzer）: 識別子解決、型チェック

3. 書換え（Rewriter）: ビュー展開、サブクエリ・トランスフォーメーション

4. 論理プラン生成: 関係代数式に変換

5. 物理プラン生成（オプティマイザ）: コスト見積もりで最適実行計画選択

6. 実行（Executor）: 物理プランの逐次実行

オプティマイザは（5）を担当。System R（IBM 1970年代）のSelinger論文（1979）が動的計画法ベースのCBOを確立し、現代RDBMSの基礎となる。

コスト計算の主要要素:

• I/Oコスト: ディスクアクセス回数×時間
• CPUコスト: 演算回数×時間
• メモリコスト: バッファプール使用量
• ネットワークコスト: 分散DBの場合

統計情報の要素:

• テーブルサイズ（行数、ページ数）
• 列のカーディナリティ（ユニーク値数）
• ヒストグラム（データ分布、Equi-width/Equi-depth/Hybrid）
• インデックス情報
• 列間の相関

結合アルゴリズム:

• ネステッドループ結合: 単純、小規模テーブル向き、O(N×M)
• ソートマージ結合: ソート前提、大規模・順序付き入力向き
• ハッシュ結合: ハッシュテーブル構築、等価結合の大量データ向き

オプティマイザはこれらをコスト比較して選択。

実務での使われ方

EXPLAIN活用:

• PostgreSQL: `EXPLAIN ANALYZE`で実行計画＋実測値
• MySQL: `EXPLAIN`/`EXPLAIN ANALYZE`/`EXPLAIN FORMAT=JSON`
• Oracle: `EXPLAIN PLAN`、AUTOTRACE、SQL Tuning Advisor
• SQL Server: 実行プラン表示、Query Storeで履歴管理

チューニング技法:

1. 統計情報更新: ANALYZE、UPDATE STATISTICS

2. インデックス設計: B+木、ハッシュ、ビットマップ、関数、複合

3. ヒント句: `/+ INDEX(table idx) /`（Oracle）等でオプティマイザに指示

4. クエリ書換え: WHERE句の順序、JOINの整理、サブクエリのCTE化

5. パーティショニング: 大テーブル分割で I/O削減

6. マテリアライズドビュー: 集計結果の事前計算

Cost-Based Optimizer の限界:

• 統計情報の精度に依存（陳腐化、偏り）
• 結合順序の組合せ爆発（N!選択肢→Bushy treeで枝刈り）
• 推定誤差の連鎖（カーディナリティ誤推定→プラン選択誤り）

Learning-based Optimizer: 機械学習で実行計画予測・選択（MIT Neo, BAO等の研究）。

試験での位置づけ

FE/AP/DBスペシャリストで頻出。①オプティマイザの役割、②実行計画と分析、③インデックス選択、④結合アルゴリズム、⑤統計情報、⑥クエリチューニング、が主要論点。DB試験では具体的なEXPLAINプラン分析・クエリ書換え問題が頻出。

選択肢の発展補足

他のRDBMS構成要素:

• トランザクションマネージャ: ACID保証、ロック・ログ管理
• バッファプールマネージャ: メモリキャッシュ、ページ置換
• WAL（Write-Ahead Logging）: 永続性保証、リカバリ
• MVCC: 多版同時実行制御
• ストレージエンジン: B+木・LSM-Tree等のインデックス構造

クラウドネイティブDB（Amazon Aurora、Google Spanner、CockroachDB、Snowflake、Databricks）は分散環境でのオプティマイザを進化させ、ノード間通信・データ局所性・並列実行を含むコスト計算を実装。Snowflakeの自動クラスタリング、BigQueryのスロット管理、SparkのCatalystオプティマイザ等が代表例。

ベクトル検索DB（Pinecone、Weaviate、Milvus、pgvector）も独自のクエリ最適化を持ち、ANN（Approximate Nearest Neighbor）インデックス（HNSW、IVF等）の選択をオプティマイザが担う。生成AI時代の新しいクエリ最適化領域として注目される分野。