（１）実行メカニズムの概要

前章ではデータベースに記録されているデータをSELECT文を使って参照できることを勉強しました。それでは、SELECT文はデータベース内部ではどのように解釈され、実行されているのでしょうか？本章ではRDBMSのSQLの実行メカニズムについて考えていきたいと思います。

まずは、下図を見てください。（これはOracleの例ですが、基本的にはどのRDBMSも同じような順序で動作します。）

【図2_2_1_1_3-1】SQLの実行メカニズム

ユーザやプログラムからSQLを受け取ったRDMBSが行う最初の処理は、そのSQL文が文法的に妥当であるかどうかをチェックする事です。この処理を担当するのが「パーサー」です。パーサーは、一般に文法的なチェックに加え、ＳＱＬ文が指定しているテーブルが実際に存在するか、ユーザーが指定したフィールド（列）に誤りがないか、ユーザがテーブルに対してアクセス権限を持っているかどうかという事も調べます。

パーサーで解析されたSQLは「クエリ・トランスフォーマ」に渡されます。ここでは、実行効率を上げるためSQL文を書き換える処理を行います。例えばビューや副問い合わせを含んだSQLを結合を使って書き換えたりします。

クエリ・トランスフォーマによるSQLの書き換えが終わったら、SQLの実行計画、つまりRDBMSが実際に実行する処理を決定します。実行計画の立案方法には大きくルールベースとコストベースの２種類があります。前者はあらかじめ決定された規則に則って静的にアクセスパス、結合方法、結合順序が選択されます。一方後者は保持しているデータの物理的なデータの偏り（ディスクにどのくらい断片化して記憶されているかなど）や、インデックスの有無などを定期的に計画ファイルとして収集し、その時々に応じて最適なアクセスプランを動的に決定します。

Oracleでは8iまではルールベース、9iから２者選択となり、10gからコストベースがデフォルト実行方針となりました（ただし、システムパラメータにより変更可能です）。しかし、コストベースの方がRDBMSの運用状況（例えば、ルールベースだと、SELECT * FROM def_cmp WHERE def_cod > 1000.のようなSQLでは必ずインデックス検索が選択されます。しかし、def_cod > 1000となるレコードの割合が多い場合は全表走査で取り出した方が高速です）に応じた実行計画を立案できるため、現在はコストベースの方が主流となっています。

よって、以降はコストベースに基づいて話を進めます。コストベースで実行計画を立案するにはクエリ・トランスフォーマにより書き換えられたSQLに対し「エスティメータ」がRDBMSの「カタログ情報（ディクショナリ）」を参照して、実行時の効率を見積もります。エスティメータにより作成された実行計画は「プランジェネレータ」に渡され、最も実行コストが低い問い合わせかどうかが判断されます。すなわち、プランジェネレータは問合せに対して使用できる可能性のある別の計画を割り出し、コストの最も低いものを取り出します。プランジェネレータで作成された実行計画は再びエスティメータに戻され、コストの最も低い計画になるまでこの作業が繰り返されます

以上が、SQLの実行メカニズムの概要です。ちなみにOracleでは「クエリ・トランスフォーマ」「エスティメータ」「カタログ情報（ディクショナリ）」「プランジェネレータ」を総称して「オプティマイザ」と呼びます。後述の章で登場する名称なので覚えておいてください。

（２）そもそもコストベースオプティマイザの「コスト」って何だ？

（３）コスト見積もりの評価に重要なインデックスとテーブル結合

---- Column ----　オプティマイザに騙されない！　HINT文