間違いなく、この決定は、パフォーマンスの問題が実際に発生した場合にのみ、後で行うことができます。これは、追加される行数やボックスの仕様などに大きく依存します。明らかに、アプリケーションの抽象化のレベル（および使用しているライブラリの制限）は、そのような変更がどれほど難しいかを判断するのに役立ちます。 。
問題が発生した場合、または問題が発生することが確実な場合は、現在のデータを保持するテーブルと履歴/削除されたデータを保持するテーブルの2つのテーブル間で削除済みフラグを分割することから始めます。あなたが言ったように、「削除された」データが管理者だけに利用可能である場合、（ほとんどのアプリケーションで）ユーザーの総数（ここでは管理者のみに限定）は問題を引き起こすのに十分ではないと考えるのが妥当です。つまり、管理者は特定のテーブルを検索するときにもう少し待つ必要がありますが、ユーザーベース（ほとんどのアプリケーションではおそらくより重要です）のレイテンシははるかに短くなります。管理者がパフォーマンスを許容できない場合は、
データへのアクセス方法に応じて、他にも簡単なトリックを使用できます。管理者がほとんどの場合特定のレコードを探している場合（たとえば、ユーザーアクティビティの「履歴」または「ログ」を読み取るのではなく）、多くの場合、古いレコードよりも新しいレコードが頻繁に表示されると想定できます。記録。一部のDBには、古いレコードよりも最近のレコードを見つけやすくするためのチューニングオプションが含まれていますが、特定のデータベースを検索する必要があります。それができない場合は、手動で行うことができます。最も簡単な方法は、 nより古いすべてのレコードを含むancient_historyテーブルを作成することです。制約と疑わしい使用パターンに応じて、数日、数週間、または数か月。新しいデータは、はるかに小さなテーブル内に存在します。管理者が特定のレコードを検索するのではなく、すべてのレコードを「閲覧」する場合でも、最初のn日間を表示することから始めて、探しているものが見つからない場合にすべての日を表示するためのリンクを設定できます（例：ほとんどのオンラインバンキングアプリケーションでは、トランザクションを閲覧できますが、特に要求しない限り、履歴の最初の30日のみが表示されます。）
うまくいけば、さらに一歩進んで、user_idまたはそのようなスキームをシャーディングする必要がなくなります。アプリケーションの残りの部分の規模によっては、とにかくこれを行う必要がある場合があります。必要になると確信している場合を除いて、最初に垂直分割を使用することを強くお勧めします（たとえば、forum_postsをsales_recordsとは別のマシンに保持する）。セットアップと保守がはるかに簡単です。user_idをシャードする必要がある場合は、googleを使用することをお勧めします;-]
幸運を。ところで、私はDBAではないので、これを一粒の塩と一緒に取ってください。