「テーブル」と「データベース」の説明は、正規化の欠如の典型的な症状です。20個の検索可能な列を持つ「テーブル」は3NFではなく、おそらく1NFでもありません。最善のアドバイスは、最初の原則に戻ってデータを正規化することです。これにより、テーブルがはるかに狭くなり、テーブルあたりの行数も少なくなりますが、確かにモートテーブルになります。ただし、結果には、テーブルごと、および全体として、インデックスも少なくなります。
そして、はるかに高速なデータベース。脂肪全体の「テーブル」は、あらゆるレベルでパフォーマンスを損なうものです。
ここではパーティションは適用されません。問題を緩和することはできません。
idPKは、追加の列とインデックス、代理、実際の主キーの代替（ただし、代替ではない）です。リレーショナルモデリング手法を使用した場合、それを排除することができ、少なくとも19の検索可能なインデックスになります。「テーブル」での深刻な作業は、たとえば、パーティションの制限からわかるように、サロゲートではなく、実際のPKを中心に行われます。
それについて話し合いたい場合は、「テーブル」と接続されているすべての「テーブル」のDDLを投稿してください。
コメントへの回答
このテーブルは「電子メール」と考えるのが最適ですが、すべて適切に正規化された多くの追加フィールド（カテゴリ/部門/優先度/ワークフロー/所有者）があります。非常に多くのタイムスタンプを含む、他のさまざまな変数もあります。
これが、 0NFでのフラットファイルの定義そのものです。「正規化」の記述されていない定義を使用していない限り、それは、あなた自身の説明によれば、まったく正規化されていません。これは、正規化が開始される前に開始する記事です。
すべてのリレーショナルDBMSベンダーが、リレーショナルデータベースを処理するために最適化されたリレーショナルデータベースエンジンを作成していることを理解する必要があります。つまり、非正規化または非正規化ではなく、正規化された構造に最適化されています。
私は学術的な議論に引き込まれることはありません。SOは質疑応答サイトであり、討論サイトではありません。要求に応じて、ファイルと接続されているすべてのファイルのDDLを投稿すると、（a）速度を上げ、（b）20以上のインデックスを回避できます（これは、この状態のもう1つの一般的な症状です）。それは特定の現実世界の問題に対処し、それを解決し、議論を避けます。
第二に、あなたは役割が混同されているようです。問題を抱えているのはあなたであり、SOに質問を投稿し、何百ものパフォーマンスの問題を修正して答えたのは私です。定義上、ソリューションはドメイン外にあります。そうでない場合は、ソリューションを解決しているため、質問を投稿することはありません。そのため、問題の解決方法を教えても機能しません。それはあなたが持っているのと同じ制限に私を縛り付け、それで私が問題を解決しないことを確実にするでしょう。
また、テストから、WHERE句に含める必要のあるテーブルをJOINに追加すると、クエリが遅くなるだけです。
実際、私は生活のためにデータベースを調整しており、多くの小さなテーブルを結合する方が速いことを示す何百ものテストがあります。コーダーのテストとコーディング機能を調べるのは興味深いことですが、それでは議論が始まるので、そうしないでください。質問に固執しましょう。（a）真剣なテストの例が必要な場合は、（b）異議を申し立てる前に私が述べたことを証明します。これは、完全に文書化され、オラクルの世界の支持者を精査し、対応するテストを行っている 1つの例です。
あなたはまた、あなたが近づいている同じ議論を殺したこの質問/回答に興味があるかもしれません。
参加には費用はかかりません。参加するファイル。いずれかの側で結合されたレコードの数。インデックスの有用性、つまりコストがかかる場所です。それが別の正規化されていないファイル（太い、幅の広い、多くのオプションの列）である場合は、遅くなることを確認してください。
とにかく、投稿された問題の修正に本当に興味がある場合は、すべてのDDLを投稿してください。そうすれば、より速く処理できます。必要なのがパーティションに関するyes/noの答えだけである場合（そして原因となる問題に対処しないため）、それも問題ありません。あなたはすでにそれを持っています。