MySQLのレコードが何行くらいが限界か知るよりパフォーマンス上げる方が建設的

挿入できるレコード数(行)は気にしなくてもいいけど、DBのパフォーマンスには気をつけたほうが良いのでインデックスとかつけようよ!って話
 

データベース使うということは、データを書き込んで読み込んで、それを扱う何かをしているのだと思います。そこで、書き込みの限界値が気になります。

なぜ限界値が気になるかといえば、パフォーマンスの部分が気になっているからではないでしょうか?

 

レコード(行)数の限界値は無い

例えば、10万レコード(行)追加してもパフォーマンスは落ちないのか?100万レコードなら?1000万レコードなら?とか思う。でも、DB自体はハードディスクの容量に依存するわけだから、1レコードあたりの容量で追加できる行数(レコード)は変わるわけです。

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値が多いけど検索要素として使うカラムはインデックスをつけておきたいです。

逆に、列の値が頻繁に更新されるカラムにはインデックスはつけない方が良いでしょう。インデックスは別枠で容量を確保されているので更新が行われればインデック側にも更新が必要になります。
検索では速くなっても、データの挿入、更新、削除の処理は遅くなってしまいます。

投稿日: 2017/10/21
最終更新日: 2017/10/28
 
筆者のご紹介
角政典@moreiic
真性のお家大好きフリーランスです。プログラムよりご飯の方が断然好き!博多出身のデブデザイナー。インドアだけど遊んでくれる人募集中!
よく検索されてる記事