今回はRDBMSの構成要素に着目し,実行プランを生成して実行されるまでの大まかな流れを説明します。登場するのは,「パーサー」「オプティマイザ」「エグゼキュータ」というソフトウエア部品,「カタログ」というデータ,「データ・バッファ」というメモリー領域です。これらのほかに,テーブルやインデックスなどのデータがあります(図1)。RDBMSの主な構成要素として,当面はこれらを押さえておけば十分です。

図1●RDBMSの主な構成要素
図1●RDBMSの主な構成要素
「パーサー」「オプティマイザ」「エグゼキュータ」の順に処理が流れ,「テーブルやインデックス」を,「カタログ」の情報を使って「データ・バッファ」に読み込む

SQL文は単なる文字列

 RDBMSがSQL文を受け取るところから説明を始めます。RDBMSが受け取るSQL文は,実は単なる文字列にすぎません。RDBMSはSQL文を受け取ると,その文字列の意味を解釈しようとします。

 具体的には,先頭に「SELECT」という文字列があれば検索,「INSERT」であれば挿入,「UPDATE」なら更新,「DELETE」なら削除――といった具合に解釈します。また,「FROM」という文字列があればその後ろにある文字列をテーブル名だと解釈し,「WHERE」という文字列があればその後ろにある文字列を検索などの条件として読み取ります。

 こうした処理を「構文解析」と言い,RDBMSのパーサーで行われます。受け取ったSQL文をパーサーが解釈することで,RDBMSは初めてSQL文の意味を知ることができるというわけです。もしSQL文の記述が文法的に間違っていると,パーサーでエラーとなり先の処理を行わず,RDBMSはエラーを返します。

数値化して最適な方法を選ぶ

 パーサーで構文解析が行われた後,SQL文の処理手続きである実行プランを自動生成します。実行プランを作成するのはRDBMSのオプティマイザです。基本的にはSQL文を受け取るたびに,その処理手続きを自動生成します。

 一つのSQL文の処理手続きは,一つとは限りません。たいていの場合いく通りもの手続きが考えられ,SQL文の内容が複雑であればあるほど何種類も考えられます。例えば,検索条件に該当するレコードを一つのテーブルから見つけるといった単純な例であっても,「全レコードを読み込む」「インデックスを利用する」――といった手続きが考えられます。オプティマイザは複数の処理手続きを導き出し,その中から最適と判断できるものを一つ選びます。そうして選ばれた処理手続きが実行プランです。

 ここで言う“最適”とは,「処理時間が短いであろう」ということを示しています。同じ結果が得られるなら,処理時間は短い方がいいですよね。実際,RDBMSで管理するレコード数が数十万,数百万と多くなると,手続きの違いによる処理時間は数倍もの差になることがあります。だからこそ,“最適な”処理手続きになっていることが重要なのです。

 では,オプティマイザは,どのようにして手続きごとの処理時間を判断しているのでしょうか。処理時間を短くするために最適な手続きを選ぶわけですから,その判断に時間がかかってしまっては本末転倒です。

 オプティマイザの判断方法には,「コストベース」と「ルールベース」という二つの考え方があります(図2)。コストベースとは,処理手続きごとに良さ(悪さ)を数値化し,その数値を基に最適と思われる手続きを選ぶ方法です。数値化したものを「コスト」と呼ぶことから,この方法をコストベースと言います。同じ結果が得られる複数の手続きを導き出し,それら一つひとつの処理時間を予測してそれをコストとして算出します。そして,コストの一番小さいものを選ぶという方法です。

図2●2種類のオプティマイザ
図2●2種類のオプティマイザ
コストベースは,カタログを参照してコストを算出する方法。SQL文を処理するたびにコストの算出を行う。一方のルールベースは,あらかじめ決まったルールに従って手続きを決める方法である

 このとき,「カラム内の値の種類数」や「カラム値の最大値・最小値」といった情報を基にします。こうした情報は「統計情報」と呼ばれ,RDBMSの管理するカタログ・データに含まれています。一般に統計情報は自動更新されないので定期的に更新する必要がありますが,実際のデータベースの状態を基にしているので,判断に間違いは少ないとされています。多くのRDBMSは,この手法を採用しています。

 もう一つのルールベースは,あらかじめ決められたルールに基づいて処理手続きを選ぶ方法です。データベースの状態を表した統計情報を参考にしません。具体的には,複数の処理手続きを導き出して優先順位の高い手続きを実行プランにする,というやり方があります。この場合,優先順位の1位は「ディスク上のレコードの位置を示す値でアクセス」,といった具合に,処理手続きごとに固定的に優先順位が付けられています。

 固定ルールに基づくので実行プランが選ばれた理由は明確になりますが,データベースの状態にかかわらず画一的に決まるので,柔軟性に欠ける面があります。以前はこの方法を採用していたメジャーなRDBMSもありましたが,今ではルールベースは主流ではなくなりつつあります。

監修:藤塚 勤也(ふじづか きんや) NTTデータ 基盤システム事業本部 オープンソース開発センタ 技術開発担当 シニアスペシャリスト
沖電気工業,タンデムコンピューターズ(現日本HP)を経て,2003年より株式会社 NTTデータに勤務。現在は,オープンソース・ソフトウエアを活用したエンタープライズ・システム向けの技術開発・技術支援に従事しており,特にシステムの中核であるRDBMSに注力している。「RDBMS解剖学」(翔泳社)を共著