大きなデータベース（> 100GB）で作業していた人たちの経験を探しています。1つまたは複数のテーブルで何百万もの行を扱う？
基本的には、すべてのアカウントに対して、システムから送信されたすべてのメッセージを格納するテーブルがあります。毎週、我々はaproxを得る。 1百万の新しい行
この表では、一部のクエリで問題が発生し始めています。私はクエリを適切に最適化する方法を理解しており、さまざまなインデックスの組み合わせを試しました。しかし、私はそれが1つのテーブルのためにあまりにも多くだと思う。
範囲条件を使用するクエリの1つは、通常、データベースを殺すものです。
あなたの経験から、このテーブルを複数のテーブル（各アカウントに1つ）に分割する方が良いでしょうか？各アカウントにはすでに独自のデータベースがあるため、このためにソフトウェアを変更することは困難ではありません。
これは、5k行の小さなアカウントの場合、これが私たちの問題を解決すると思うでしょう。
私は直接のMySQLで働いていません。私はSQL ServerとOracleの人です。しかし、私は、MySQLがtable partitioningを持っていることを知っています。大きなテーブルを分割し、それらをファイルに分散します。パーティションにルールを設定し、その仕組みをすべて設定することができます。
もう1つのヒントは、データをアーカイブテーブルに分割することです。たとえば、バックエンドで、日付でメッセージを検索する必要があり、日付範囲が一定の時間を超えた場合、バックエンドはアーカイブテーブルで検索を行います。それ以外の場合は、メインテーブルを検索します。これにより古いメッセージをアーカイブすることができます。
MySQLは一般に、1つのテーブルではなく複数のテーブルを処理する方が高速です。データを複数のセクション（1つのテーブルのユーザー、別のテーブルの各ユーザーのアクションなど）に分割することができれば、一般的に高速になります。データを複数のテーブルに分割する場合は、それらをすべてIDと一緒に接続する必要があることに注意することが非常に重要です。
いくつかの有用な情報： http://dev.mysql.com/doc/refman/5.1/en/multiple-tables.html
MySQLでテーブルを手動でパーティション化することは、地雷のビットです。一般的に、データを異なるタイプ（つまり、実質的に異なる列のセットを持つテーブル）のを含む複数のテーブルに分割することができない場合は、インデックスを追加する方が一般的です。ただし、データセットが真に大きくなっているため、単一のデータベースにはあまりにも多くのデータが含まれていると、サーバー上のシャーディングが役立ちます。
私はかなり理解していませんが、各アカウントに独自のデータベースがありますが、アカウントごとに別々のテーブルに分割していますか？
もう1つのオプションは、誰も見たことがないので、shardingです。これは素晴らしい技術ですが、適切に使用すると縮尺を変えることができます。あなたがますます細分化するにつれて、応答時間に問題が生じます。また、タプルごとに（ジョインなしの行ごとに）格納されるデータ量に応じて、正規化手法を使用してフィールドを別々のテーブルに分割することができます。あなたのデータベースにどれくらいの距離があるのかは分かりませんが、ちょっとした提案です。