データベースのインデックスは意識されないで使われていることが多いです。
インデックスを付けすぎると遅いとか、技術者の中でも間違った認識も多いです。
ＳＱＬを書くときには、どのインデックスをどういう順番で使うか考えて記述する必要があります。
では、身近で同種の大量のデータを扱うもので、カラオケを例に考えてみましょう。
カラオケには、通常、最低３つのインデックスが存在します。
- 歌手名順 歌手名、曲名の順でユニークキー
- 曲名順 曲名、歌手名の順でユニークキー
- 登録順 通常は目にしないが、リモコンで押すコード番号（主キー）
（アーティスト順と言わないところが年齢をあらわしていますね）
カラオケとは、データベースで言うと、主キーと複合インデックスが２つ存在するという、割と複雑な構造のテーブルになります。
他にも、カテゴリー別（演歌・ＰＯＰＳ…）とかもあるかもしれませんね。
この場合は、３つの項目がキーとなる複合インデックスになります。
さて、私は新人歓迎会でカラオケボックスに出かけました。
そこで、のってきた私は十八番（おはこ）の「『ｘｘｘｘｘｘ（曲名）』を入れて」と新人君に頼みました。
新人君：『ｙｙｙｙｙ（歌手名）の曲ですよね』
と言って、歌手名順で一発で検索
私：『それそれ！』とノリノリ
となればハッピーですが…
いつまでたっても曲が入らない。
私：『ない？』
・・・
私：『なんで歌手名順で探してるの？』
新人君：『いつも歌手名順を使っているので…』
私：『おまえな～（怒）』
・・・
新人君は小一時間問い詰められることになるでしょう。
（わかる人だけ笑ってください）
実際にこんな新人君はいませんが、もし、いたら笑い話ですよね。
小学校の低学年でも『アンパンマンのテーマ』を曲名順を使って、自分で探せるのではないでしょうか？
データベースなんて知らない小学生でも、データベースエンジンに代わり、複合インデックスがいくつもあるテーブルに対するアクセスを難なくやっているわけです。
つまり、データベースエンジンは魔法でもなんでもなく、大きく見れば人間と大差ない処理をします。
大層に『自動で適切なインデックスを選びます』なんて宣伝文句が書いてありますが、『アンパンマンのテーマ』を探すときは、自動で曲名順（インデックス）を使います。
程度のことなのです。
であるなら、コンピュータを使って業務の効率化を図るプログラマ・ＳＥと呼ばれる人が、どのインデックスをどのように使うかということを気にしない方がおかしいのではないでしょうか。
小学生でも自然に出来ることではないですか？
確かに、ＳＱＬの文法が合っていれば、要求している正しい答えは返ってきます。
マシンが速くなって、少々下手糞でもそれなりの処理速度が出るようになってきていますから、『正しい答えが出てくるから、そんなことまで気にしなくても…』という技術者が多いのが、残念ながら実情です。
しかし、よく考えてみてください。
曲名で指定しているのに、歌手名順で調べても歌いたい曲は探せます。
という新人君は正しいですか？
なかなか曲を探せない新人君が素早く探せるように、新人君にページを速くめくる訓練をさせる（データベースで言えばマシンを速いものに代える）ことは正しいですか？
笑い話でしかないですよね。
だから、どう記述すれば適切なインデックスを使うようになるのか、常に気にしながらコーディングしましょう。
具体的にはチューニングガイドなどを読んでみてください。
（もちろん、使うインデックスを直接記述しても良いのですが…）
では、冒頭で書いた『インデックスを付けすぎると遅くなる』ということについてです。
インデックスをカラオケで例えると
ハードディスクの容量 ＝ 本（紙）の量
メモリーの容量 ＝ 本を置くテーブルの大きさ
となります。
ハードディスクにも、メモリーにも限界がありますので、めったやたらに作ればよいというものではありません。
インデックスを追加するというのは、カラオケで言えば、カテゴリー別、人気順、サビ順などなどのカラオケ本を追加するのと同じです。
作ればお客様は探しやすくなるでしょう。
でも、テーブルの上は、本でいっぱいになって料理もドリンクも置けなくなる（データベースで言えば他の処理が出来なくなる）かもしれません。
また、新曲が出るたびに作り直すカラオケ本が増える。
つまり、時間がかかるわけです。
『インデックスを付けすぎると遅くなる』というのは間違いではありません。
実際のデータベースでは、インデックスを１つ付けたため１件のデータを追加するのに 0.1秒掛かっていたのが、0.15秒になった。
ということが起きます。（実際には、もう少し短い時間でしょう）
しかし、オペレータにとって 0.1秒 も 0.15秒 も変わりませんから、オペレーターが１件ずつ入力して、このデータを数ヶ月分集めて集計をするようなシステムであれば、インデックスをケチらずに付けた方が良いかも知れません。
（オペレータ数が多いときは注意が必要ですが…）
ちなみに、昔は、インデックスを付けすぎるとオペレータが登録ボタンを押して２、３秒掛かることになったので、オペレータが入力するシステム（オンライントランザクション型システム）では、インデックスを付けないようにと言われていました。
そのためか、未だに『更新が遅くなるから付けないで！』と言われることも少なくないです。
もちろん、バッチで大量更新する場合には慎重にしなくてはいけませんが、テストマシンで実験してみれば『更新が遅くなる』は既に迷信に近いものだということが分かることでしょう。
また、難しいとされるチューニングについてですが、カラオケを想像すれば簡単に理解できるものも多いです。
たとえば、
データを大量に追加、変更した場合は、インデックスを作り直した方が良い。
という法則があります。
これは、カラオケ本ではｘ月の新譜という形で、巻頭や巻末に追加の曲が貼られていくことが多いですね。
この貼られた新譜が増えれば増えるほど、歌いたい曲を探すのに時間が掛かるということは想像できるでしょう。
データベースでも似たような現象が起きます（断片化と呼ばれる）
ですから、大量に追加・更新したときは、インデックスを一度捨てて、再作成した方が速くなることが多いです。
もちろん、大量に追加する前にインデックスを捨てて、追加が終わった後に作成した方が効率的ですね。
・・・というように、データベースは、意味を理解して扱えば決して難しいものではありません。
データベースに限らず、身近な例に置き換えて考えていけば、コンピュータシステムはそれほど難しいものではないので、肩肘張らずに付き合ってみましょう。
<< 第２３回目 「SQLについて（安い、且つ 速いシステムを作るには) のまとめ」 | | 第２５回目 「ラジオのデル(DELL)」 >>
コラムの全インデックス
