はじめに

結果として，SQLのような関係型の言語は非手続き型の言語と呼ばれるが，これはユーザは「いかに」ではなく「何を」を指定する―つまり，獲得するための手続きを指定することなしにユーザは何が欲しいかをいう―からである。

─⁠─ Christpher J. Date（注1）

Webの入力フォームであれ，コマンドラインツールであれ，インタフェースにかかわらず，リレーショナルデータベースに対する操作はSQLという専用の言語で行われます。ユーザ（プログラマ含む）が意識的にコーディングするのは通常このSQLレベルまでで，あとはDBMSが処理を終え，結果を返却するのを待つのみです。SQLとRDBMSにおいては，ユーザはデータのありかを知る必要もなければ，そこへのアクセス方法も考えません。そういう仕事は，全部DBMSに任せています。

このプロセスは，通常「プログラミング」と呼ばれるものとはかなり異なります。普通，データの検索や更新をプログラミング言語によって行う場合，どこにあるデータをどのように探すか，ということを細部に渡って記述しなければなりません。

注1）

第4回（3）の参考文献［1］p.68より引用。

手続き型と非手続き型の違い

この態度の違いは，良いとか悪いというものではなく，ソフトウェアの設計思想の違いです。C言語，JavaからRubyに至るまで，手続き型を基礎とする言語とシステムにおいては，ユーザがデータアクセスのための手段（How）を責任持って記述することが前提です。他方，非手続き型であるリレーショナルデータベースはその仕事をユーザからシステム側に移管しました。その結果，ユーザのすることは対象（What）の記述だけに限定されたのです。

権限委譲の功罪

リレーショナルデータベースが，このような大胆な権限委譲を断行したことには，もちろん正当な理由があります。「⁠そのほうがビジネス全体の生産性は上がるから」です。現在の状況を眺めると，この言葉は半面正しく，半面間違っていました。正しかったことは，RDBMSがシステムの世界の隅々にまで浸透したことからわかります。間違っていることは，それでもやっぱり私たちはRDBMSを扱うのに苦労しているからです。SQLは思ったほど簡単な言語じゃなかったし，パフォーマンスが悪いこともよくあります。

本稿では，こうしたRDBMSが抱える諸刃の剣とも言うべきパフォーマンスの部分について，いつもどおりDBMSの内部動作を明らかにしながら，その対処方法を探っていきます。

対象読者

• RDBMSのパフォーマンス問題に悩まされたことのある人
• 「実行計画」という言葉を聞いたことがあるが，実際に見たことはない人
• 「実行計画」を見たことはあるが，どう見ればよいか理解できなかった人

対象環境

• すべてのリレーショナルデータベース

データへのアクセス方法はこうやって決まる

RDBMSにおいて，データアクセスの手続きを決めるモジュールがクエリ評価エンジンです。これは，ユーザから送信されたSQL文を最初に受け取るモジュールでもあります（注2⁠）⁠。クエリ評価エンジンは，さらに複数のサブモジュールから構成されています。

注2）

DBMSのアーキテクチャの全体像については，本連載第1回を参照してください。

クエリが処理される流れ

ここでクエリがどのように処理されて，実際にデータアクセスが実行されるのかをおおまかに図示すると，図1のようになります。

パーサ

①パーサ（parser）の役割は，名前のとおり構文解析です。つまり受け取ったSQL文（クエリ）を一度バラバラの要素に分解し，それをDBMSが処理しやすい形式に変換することです。

なぜこの処理が最初に必要かといえば，第一に，受け取ったSQL文が常に構文的に適正である保証がないため，整合性チェックが必要だからです。ユーザがカンマを書き忘れたり，FROM句に存在しないテーブル名を書いたりしてきたときには，「⁠書類審査」で落第させる必要があります。

第二の理由は，SQL文を定型的な形式に変換することで，DBMS内部での後続の処理が効率化されるからです。構文解析は，SQLに限らず一般のプログラミング言語のコンパイル時にも同様に実行されるものです。

オプティマイザ

書類審査をパスしたクエリは，次にオプティマイザ（optimizer）に送られます。オプティマイズの和訳に最適化という語が当てられているとおり，ここで「最適」なデータアクセスの方法（実行計画）が決定されます。この処理がDBMSの頭脳におけるコアです。

オプティマイザは，複数のアクセス経路，インデックスの有無，データの分散や偏りの度合い，DBMSの内部パラメータなどの条件を考慮して，選択可能な多くの実行計画を作成し（②プラン生成⁠）⁠，それらのコストを計算して（③コスト評価⁠）⁠，最も低コストな一つに絞り込みます。

カタログマネージャ

そのとき，重要な情報を提供するのが④カタログマネージャです。カタログとはDBMSの内部情報を集めたテーブル群で，テーブルやインデックスの統計情報が格納されています。そのため，このカタログの情報を単に「統計情報」とも呼びます。本稿でもこの呼び名を使います。

RDBMSがデータアクセスの手続き決定を自動化している理由は，候補の数が多いうえに，それら個々のプランについてしらみつぶしにコスト計算をして，互いを比較考慮しなければならないためです。このような計算はコンピュータにより高速に処理可能ですので，オプティマイザに任せたほうが得です。

プラン評価

オプティマイザが1つの実行計画に絞り込んだら，それを受け取って実行するのが，⑤プラン評価の処理です。実行計画というのは，あとで実際にいくつかのサンプルを見ていきますが，まだそのままDBMSが実行できるようなコードにはなっていません。むしろ人間が目で読むことができる，本当の「計画書」です。そのため，これを評価して手続き型のコードへと変換することが必要です。