ぷろめし|プログラミングよりも飯が好きHomeHome軽い備忘録MySQLMySQLのレコードが何行くらいが限界か知るよりパフォーマンス上げる方が建設的データベース使うということは、データを書き込んで読み込んで、それを扱う何かをしているのだと思います。そこで、書き込みの限界値が気になります。インデックスをつける基準レコード(行)数の限界値は無い例えば、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値が多いけど検索要素として使うカラムはインデックスをつけておきたいです。逆に、列の値が頻繁に更新されるカラムにはインデックスはつけない方が良いでしょう。インデックスは別枠で容量を確保されているので更新が行われればインデック側にも更新が必要になります。検索では速くなっても、データの挿入、更新、削除の処理は遅くなってしまいます。真性のお家大好きフリーランスです。プログラムよりご飯の方が断然好き!博多出身のデブデザイナー。Cloudがそんなに良いのか?CCとCSの違い。Getewayの原因と意味についてフォトショップのドロップレットが通信できない。