【MySQL】一つのデータベースに対するテーブル数について

Question

MySQLの処理速度について疑問点があります。

お尋ねしたいことは、
一つのデータベースに
いくつのテーブルまで保持するものなのでしょうか？

処理速度について
二つに分けられると思いました。

一つは、該当のテーブルを見つけるまでの処理。
二つは、該当のテーブルのレコード件数。

後者は○○万レコードで処理が重くなるなどの記述をみることがありますし、
重くなることも想像ができます。

前者については、
DBに接続する際に、DB名とユーザ名、パスワードを入力しますが、テーブルが多ければ多いほど、セレクトするのに時間がかかるのでは？と思いました。

この考えは合っているのか？
目安となる数があるのか？
データベースは同じでもユーザーアカウントを分けるのか？
疑問点が次々と浮かび、
こちらに質問をいたしました。

どうぞよろしくお願い致します。

Answer 1

疑問点が次々と浮かび、こちらに質問をいたしました。

疑問が沸いたら、先ずは調べるのが普通。

テーブルが多ければ多いほど、セレクトするのに時間がかかるのでは？と思いました。
この考えは合っているのか？

数が多くなれば、時間が掛かるというのは当然ですけど、気にするような値ではありません。
利用していてそういったところが気になるDBMSは誰も使わないでしょう。

目安となる数があるのか？

何事も無限というのはないですから、当然上限はありますが、そもそも、万を超えるテーブルとか想像つきませんし、千に近いと、設計を疑うレベルです。

殆どのDBMSは概ねシステムカタログといった情報をみるとテーブルがどのように管理されているかが分かりますので、興味があるなら調べられると良いでしょう。

Comments

[退会済みユーザー]

お忙しい中、ご丁寧に教えていただきありがとうございました。
システムカタログは初めての用語でしたので、
今後の参考にさせて頂きます。
ありがとうございました。

Answer 2

「必要なだけ」
です。

どれほど必要となるかは要件次第。
規模次第ではありますが、大抵は負荷テストが行われますし、
設計段階でテストデータ入れて検証も行います。
それによりSQLの見直し、テーブルの正規化も可能な範囲で行います。

つまり設計段階で「どれくらいのデータ量が想定されて、どれくらいのパフォーマンスを目指すか」を決めておくことになります。
「性能」や「運用」「拡張性」含めた、非機能要件にあたります。

帳簿書類等の保存期間（電子帳簿も含む）が国としても定義されていますが、データは半永久に保持し続けるわけではなく、サーバ容量も有限なので、「どれくらいの期間保持するデータなのか」を定義します。
「その期間でどれくらいのデータ量になるか」を先に概算しておく必要がありますし、その概算を元にサーバ容量が決まります。

そして、「期間が過ぎたデータをどうするのか」「バックアップは」なども決めます。
単純に削除するのか、DB分割して別サーバに保持するのか等々、様々な選択肢の中から決めます。

決められた内容に基づき、運用します。
※もちろん状況は刻一刻変わりますので定期的な見直しすべきです

---

ここまでほとんど「データ量」に関して言及してきましたが、
「テーブル数」も同じようなものだと思って良いです。

必要だからそのテーブルを作ったわけですから、
数を気にして正規化が行われない方が問題です。

定期的な見直しは必要ですけどね。

一つは、該当のテーブルを見つけるまでの処理。

SELECT時にテーブル1つしか対象としないなら「見つけるまで」なんて存在しないのでは。
テーブルが多いから単純SELECTが遅くなるなんてことはないはずです。
上から1つ1つ見に行くわけではなく、いきなりそのテーブルを見るわけですから。
データベースのメリットはそこです。
データ量が多くてもいきなりそのデータを取り出せるようになっています（もちろんINDEXは適切に貼られているべき）

Comments

[退会済みユーザー]

お忙しい中、ご丁寧に教えていただきありがとうございました。
頂いた内容を踏まえて勉強します。

＞SELECT時にテーブル1つしか対象としないなら「見つけるまで」なんて存在しないのでは。
たしかし、そう思います。

どうもありがとうございました。