データベース使うということは、データを書き込んで読み込んで、それを扱う何かをしているのだと思います。そこで、書き込みの限界値が気になります。
なぜ限界値が気になるかといえば、パフォーマンスの部分が気になっているからではないでしょうか？
例えば、10万レコード(行)追加してもパフォーマンスは落ちないのか？100万レコードなら？1000万レコードなら？とか思う。でも、DB自体はハードディスクの容量に依存するわけだから、1レコードあたりの容量で追加できる行数(レコード)は変わるわけです。
例えば、WEBサーバーに100GB(104,857,600KB)の残容量があったとして、1レコード1KBだとするなら、1億レコード(行)は保存できることになります。1億も保存できれば、1日10万レコードを保存したとしても2年半は大丈夫(笑)
1億レコードなんて現実的じゃないので、50万レコードくらいで考えます。
すると、問題になるのがデータ参照のスピードです。50万行を毎度読み込んでからマッチするデータを出力するなんて、待ちぼうけさせられるのは必至。
データベースは、基本的に指定されたテーブルを全て読み込んで、マッチするデータを参照します。テーブルのサイズがデカくなればなるほど、作業が大変になるのが想像できます。
これをO(n)問題というらしい。
O(n)とは、テーブル内のレコード数をnとして、特定のレコードを見つけるための処理量(オーダー)がレコードnに比例することを指します。
要は、レコードが増えれば処理が大変ってこと。
レコード数が何万行になろうと、素早く動いてくれるなら心配ありません。むしろ管理が楽でありがたい。これを実現するのがインデックス。
インデックスは、辞書の巻末とかにある目次・索引みたいなやつ。
インデックスをつければ検索が速くなるってことだけど、全てのカラムにインデックスを付けると検索は速くなるけどサーバー容量を圧迫するし、更新の度にインデックスの更新も必要になるので、結局、処理時間も犠牲になる。
全てにインデックスを付けるのは現実的ではないにしても、インデックスを付ける基準が欲しい。その基準は、よく使うカラムかどうかです。
WHERE句でよく基準にするカラムがあるなら、それにインデックスを付けると効果的。あと、NULL値を検索要素にしない仕様なので、NULL値が多いけど検索要素として使うカラムはインデックスをつけておきたいです。
逆に、列の値が頻繁に更新されるカラムにはインデックスはつけない方が良いでしょう。インデックスは別枠で容量を確保されているので更新が行われればインデック側にも更新が必要になります。
検索では速くなっても、データの挿入、更新、削除の処理は遅くなってしまいます。
