私はお互いにメッセージを送るメンバーがいるウェブサイトを持っています。メッセージを送るのが好きなメンバーが数人になりつつあります。
現在、私は、ステータス（未読、保存済みなど）を示すさまざまなステータスIDを持つ「メッセージ」という巧妙なタイトルの適切なリレーショナルテーブルにメッセージが格納されていると述べました。これが事後であることはわかっていますが、このテーブルを他のいくつかのテーブルに分割する必要があると考えています (たとえば、ステータスの種類ごとに複数の場合など)。最善の方法はわかりません。それについて。
私にはいくつかのアイデアがありますが、どれもロケット科学ではありませんが、これに「標準的な解決策」があるかどうかに興味があります. Google はそうではないと提案していますが、この種の問題は、stackoverflow のような場所以外ではそれほど一般的ではないと思います。
すでに行ったことがある人はいますか？
私は間違いなく「メッセージ」テーブルを複数に分割します。例えば：
MessageStatusメッセージMessageText
このように、誰かの受信トレイにアイテムのリストを表示する場合、最大シーク速度については、より小さく固定長の列である「メッセージ」テーブルをスキャンするだけで済みます。誰かがメッセージ本文を開いて表示したい場合は、「MessageText」テーブルを押します。「メッセージステータス」は、「メッセージ」テーブルにtinyintFKで結合するための単なるルックアップテーブルです。
おそらくミディアムテキストの列を持つ1つのテーブルよりもはるかに高いパフォーマンスが得られます。
特定の期間よりも古いものをアーカイブするアーカイブ プロセスを考えたことはありますか?
適切なインデックス作成と微調整を行うと、スペースに問題がない限り、複数のテーブル間でメッセージを移動する必要があるかなりの数のメッセージが必要になります。
メッセージ テーブルに大量のデータが含まれていても問題はありません。本当に必要がない場合は、分割する必要はありません。
このテーブルのパフォーマンスが気になる場合は、まずニーズに応じてストレージ エンジンを賢く選択してください。書き込みが集中するため、InnoDB を使用することをお勧めします。次に、読み取りを高速化するためにインデックスを調べます。
テーブルが本当に大きくて遅くなる場合にできることは、2 つのテーブルを作成することです。
MyISAM ストレージを使用する messages_archive テーブル (「アーカイブされた」メッセージの高速な取得と検索にのみ使用されます)。
InnoDB ストレージを使用する messages_inbox テーブル: これは、新しいメッセージが頻繁に挿入されるテーブルです。
オプション:
ところで、これはあなたが言ったように「標準的な解決策」ではなく、単なるアイデアです。:)
編集 ：
あなたのコメントから、あなたが探しているのは実際には「パーティショニング」であることを理解しています。
さまざまな MySQL パーティション タイプを使用すると、範囲、リスト、キー、またはハッシュによってデータを物理的に分離できます。