質問: MySQLの処理速度について疑問点があります。 お尋ねしたいことは、 一つのデータベースに いくつのテーブルまで保持するものなのでしょうか? 処理速度について 二つに分けられると思いました。 一つは、該当のテーブルを見つけるまでの処理。 二つは、該当のテーブルのレコード件数。 後者は○○万レコードで処理が重くなるなどの記述をみることがありますし、 重くなることも想像ができます。 前者については、 DBに接続する際に、DB名とユーザ名、パスワードを入力しますが、テーブルが多ければ多いほど、セレクトするのに時間がかかるのでは?と思いました。 この考えは合っているのか? 目安となる数があるのか? データベースは同じでもユーザーアカウントを分けるのか? 疑問点が次々と浮かび、 こちらに質問をいたしました。 どうぞよろしくお願い致します。
回答: 「必要なだけ」 です。 どれほど必要となるかは要件次第。 規模次第ではありますが、大抵は負荷テストが行われますし、 設計段階でテストデータ入れて検証も行います。 それによりSQLの見直し、テーブルの正規化も可能な範囲で行います。 つまり設計段階で「どれくらいのデータ量が想定されて、どれくらいのパフォーマンスを目指すか」を決めておくことになります。 「性能」や「運用」「拡張性」含めた、非機能要件にあたります。 帳簿書類等の保存期間(電子帳簿も含む)が国としても定義されていますが、データは半永久に保持し続けるわけではなく、サーバ容量も有限なので、「どれくらいの期間保持するデータなのか」を定義します。 「その期間でどれくらいのデータ量になるか」を先に概算しておく必要がありますし、その概算を元にサーバ容量が決まります。 そして、「期間が過ぎたデータをどうするのか」「バックアップは」なども決めます。 単純に削除するのか、DB分割して別サーバに保持するのか等々、様々な選択肢の中から決めます。 決められた内容に基づき、運用します。 ※もちろん状況は刻一刻変わりますので定期的な見直しすべきです ここまでほとんど「データ量」に関して言及してきましたが、 「テーブル数」も同じようなものだと思って良いです。 **必要だからそのテーブルを作った**わけですから、 数を気にして正規化が行われない方が問題です。 定期的な見直しは必要ですけどね。 > > 一つは、該当のテーブルを見つけるまでの処理。 > > > SELECT時にテーブル1つしか対象としないなら「見つけるまで」なんて存在しないのでは。 テーブルが多いから単純SELECTが遅くなるなんてことはないはずです。 上から1つ1つ見に行くわけではなく、いきなりそのテーブルを見るわけですから。 データベースのメリットはそこです。 データ量が多くてもいきなりそのデータを取り出せるようになっています(もちろんINDEXは適切に貼られているべき)