たとえば、タスクを含むテーブルがあります。一部のタスクは新規または進行中の段階にありますが、他のタスクはアーカイブ段階にあります。つまり、それらのタスクは処理済みであり、元に戻る可能性は低いということです。「現在の」タスクへのクエリが高速になるように、アーカイブされたタスクを同じスキーマの別のテーブルに配置するのが賢明だと考えていました。そうですか？
(検索結果のように) アーカイブされたタスクを含む現在のタスクを表示する必要がある場合は、単純に 2 つのテーブルを結合します。
これは正しいですか？何かメリットはありますか？水平断片化と呼ばれるものだと思います。MySQL InnoDB を使用しています。パフォーマンス上の利点を実際に得るために、テーブル定義に何か特別なことをする必要がありますか?
ありがとう！！
同じスキーマを持つ別のテーブル
これが良いアイデアかどうかはわかりませんが、DRY (同じことを繰り返さないでください) を覚えておいてください。一方のスキーマを変更する必要がある場合は、もう一方のスキーマも変更する必要があります。これにより、バグが発生する可能性があります。
また、
時期尚早の最適化は諸悪の根源
現在、データベース クエリの実行が遅すぎますか? そうではないと思います。
パーティショニングは、お客様のような特定の要件に対応する手法です。基本的に、日付などのデータのメジャーに基づいて、データを論理的に分離できます。
ただし、テーブルを分割したくない場合は、現在のタスクに対して頻繁にテーブルをスキャンする必要がある場合、または何らかの理由で分割する場合を想定して、全体的なスループットを向上させる目的で、タスクを 2 つのテーブルに分割することをお勧めします。テーブルにインデックスを作成することに消極的 (たとえば、クエリの種類を予測するのが難しいため)。このような場合、この分離は、現在のタスクのテーブルのサイズを最小限に抑えるのに役立ちます。そのため、通常はフル テーブル スキャンが必要なクエリが改善される可能性があります (特にアドホック クエリの場合)。
ただし、時間の経過とともに、アーカイブされたタスク テーブルのサイズも大きくなり、この増大がこのテーブルに対して実行されるクエリのパフォーマンスに影響し、アーカイブ テーブルにいくつかのインデックスを作成することが必要になる場合があることに注意してください。 .