開発者はインデックスを知る必要がある

SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？

SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。

SELECT date_of_birth
  FROM employees
 WHERE last_name = 'WINAND'

SQLのクエリは、データを要求する英語の文として読むことができます。通常SQLを書く時には、データベースの内部動作やストレージシステム(ディスクやファイルなど)に関する知識は必要とされません。データベースに対して、どのファイルを開き、どのように要求する行を見つけるかを指示する必要はないわけです。多くの開発者は、何年もSQLを触っているにもかかわらず、データベースの内部で行われている処理についてはほとんど知らないでしょう。

何が欲しいのかと、どのようにそれを取得するかという関連性を分離することは、 SQLにおいては非常に有効に機能しています。しかし、それでも完璧ではありません。パフォーマンスの問題にたどり着く時、このような抽象化は逆効果になります。前述の通り、SQL文を書く人は、どのようにデータベースが文を実行するかを知らないからです。つまり、SQL文を書いた人はクエリの実行が遅くても責任を持てないのです。しかし、経験的には逆のことが言えるでしょう。つまり、パフォーマンス上の問題を避けるためには、開発者はデータベースについて多少なりとも知っておく必要があるということです。

すなわち、開発者が知るべき唯一のことは、どのようにインデックスを張るか、ということになります。データベースにインデックスを張ることは、実際のところ、開発のタスクのひとつです。それは、正しいインデックスを張るのに最も重要な情報は、ストレージシステムの設定やハードウェアの構成ではないからです。データへのアクセスパスに関する情報は、データベース管理者(DBA)や外部のコンサルタントには詳しく分からないことです。アプリケーションをリバースエンジニアリングしてそういった情報を集めるのは、かなりの時間を要することでしょう。一方で、開発者はこの情報を知っているに違いないのです。

この本では、インデックスについて開発者が知るべきこと全てを書いていますが、それ以上のことは扱いません。さらに詳しく言うと、この本では最も重要なインデックスである、Bツリーインデックスのみを取り上げます。