質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

87.59%

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

解決済

回答 2

投稿

  • 評価
  • クリップ 0
  • VIEW 225

score 49

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

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

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

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

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

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

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

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 2

+2

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

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

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

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2021/04/24 12:07

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

    キャンセル

checkベストアンサー

+1

「必要なだけ」
です。

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

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

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

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

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


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

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2021/04/24 12:06

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

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

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 87.59%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る