問題の詳細をすべて説明したいので、これはやや長い質問です。
システムの説明
外部システムからの着信メッセージのキューがあります。メッセージはすぐにたとえばINBOXテーブルに保存されます。テーブルからジョブチャンクをフェッチするスレッドワーカーはほとんどありません（最初にいくつかのメッセージをUPDATEでマークし、次にSELECTでマークされたメッセージをマークします）。ワーカーはメッセージを処理せず、メッセージコマンドに応じて、メッセージをさまざまな内部コンポーネント（「プロセッサ」と呼ばれる）にディスパッチします。
各メッセージには、いくつかのテキストフィールド（最長は200 varcharsのようなもの）、いくつかのID、いくつかのタイムスタンプなどが含まれます。合計10〜15列。
メッセージを処理する各内部コンポーネント（つまりプロセッサ）は、動作が異なります。メッセージをすぐに処理するものもあれば、HTTPを介してシステムの他の部分と通信する場合でも、長い操作をトリガーするものもあります。つまり、INBOXからのメッセージを処理してから削除することはできません。そのメッセージをしばらく処理する必要があります（非同期タスク）。
それでも、システムには最大10個のプロセッサがあまり多くありません。
メッセージはすべて内部的なものです。つまり、ユーザーがメッセージを閲覧したり、ページ分割したりすることは重要ではありません。ユーザーは処理済みの関連メッセージのリストを必要とする場合がありますが、これはミッションクリティカルな機能ではないため、高速である必要はありません。一部の無効なメッセージが削除される場合があります。
予想されるトラフィックが非常に多い可能性があることを強調することが重要です。データベースの設計が悪いためにボトルネックが発生することは望ましくありません。データベースはMySqlです。
決断
決定の1つは、すべてのメッセージに対して1つの大きなテーブルを持たないことです。いくつかのフラグ列には、さまざまなメッセージの状態が示されます。アイデアは、プロセッサごとにテーブルを用意することです。メッセージを移動します。たとえば、受信したメッセージはINBOXに保存され、ディスパッチャによってPROCESSOR_1テーブルなどに移動され、最後にARCHIVEテーブルに移動されます。そのような動きは2つ以上あるべきではありません。W
処理状態にある間、処理固有の状態を示すためにフラグを使用することを許可します（存在する場合）。つまり、PROCESSOR_Xテーブルはメッセージの状態を追跡する場合があります。現在処理中のメッセージの数が大幅に少なくなるためです。
これは、すべてに1つのBIGテーブルを使用しないためです。
質問
私たちはメッセージを動かしているので、これは大量の場合どれほど高価なのだろうか。次のシナリオのどれが優れていますか？
（A）説明されているように、すべての別個の同様のテーブルを持ち、完全なメッセージ行を移動します。たとえば、INBOXから完全な行を読み取り、PROCESSORテーブル（いくつかの追加の列を含む）に書き込み、INBOXから削除します。
また
（B）コンテンツの物理的な移動を防ぐために、コンテンツを格納するだけの（まだ状態ではない）1つの大きなMESSAGESテーブルを作成する方法について説明します。上で説明したように、他のテーブルもありますが、メッセージのIDと追加の列のみが含まれます。そのため、メッセージが移動しようとしているときに、物理的に移動するデータははるかに少なくなります。IDだけです。メッセージの残りの部分は、常に変更されずにMESSAGEテーブルに残ります。
言い換えると、1つの小さなテーブルと1つの大きなテーブルの間のSQL結合にペナルティがありますか？
あなたの忍耐に感謝します、私が十分に明確であったことを望みます。