5つ以上の列の主キーは、大規模な（1億を超える）テーブルに悪影響を及ぼしますか？
私はいくつかの実際のDBの問題について読んでおり、1つのプロジェクトで1億行に加えて、プライマリとして5つの列を持つテーブルがありました。これは悪いことだと思っていますが、正確な理由を誰かに教えてもらえますか？
テーブルは一種のマイクロロールアップ/集計テーブルなので、5つの列は（day、market_id、product_id ...）のようでした。最初は5列の主キーは理想的ではないと思っていましたが、考えれば考えるほど、それが悪かった理由を思い付くことができませんでした。
これは、会社のエンジニアの半分との深夜の議論でした。誰かがこれが悪いデザインだと言ったばかりで、ある上級エンジニアが同意しましたが、なぜその理由について実際に飛び込んだ人はいません。したがって、自分で問題を調査しようとしています！
非常に複雑な主キーにはパフォーマンスの問題があります。また、単純な主キーの場合と同様に、重複を防ぐことはできません。
ただし、主なキーが6個程度のコンポーネントで構成されるテーブルを頻繁に生成する設計パターンが1つあります。スタースキーマのファクトテーブルです。スタースキーマのファクトテーブルに6つのディメンションがある場合、主キーには6つのコンポーネントがあります。主キーが宣言されていないファクトテーブルを見たことがありません。ETLプロセスを慎重に作成する必要がある場合でも、オーバーヘッドの価値は十分にあると思います。
一部のレポートデータベースは、スタースキーマが明示的に設計されていなくても、スタースキーマのパターンを模倣しています。
1億行以上は、ファクトテーブルの場合、特に今日のビッグデータの場合は、それほど大きくありません。
問題のテーブルは、ロールアップ/集計テーブルでした。
それからそれは素晴らしいだけでなく、それは「正しい」です。
そして、それはdayで始まるので、要約表のようなにおいがします。
セカンダリインデックスはありますか？ InnoDBを使用している場合、残りのPRIMARY KEY列はセカンダリインデックスの最後に追加されることに注意してください。繰り返しますが、これは必ずしも問題ではありません。
1億行は、ロールアップには大量です。テーブルが細かすぎるようです。つまり、おそらく（date、a、b、c、d）の場合、（date、a、b、c）、（date、b、c、d）、（date、c、 d、a）、（date、d、a、b）（またはいくつかの適切な組み合わせ）。そうすることで、各行がわずか1,000万行になる可能性があるため、レポートの柔軟性はほぼ同じになり、レポートはさらに高速になります。
または、（週、a、b、c、d）に切り替えて、たった1400万行になる場合もあります。 （おそらくもっと。）
PARTITIONを使用して剪定を容易にする --- 高速取り込み --- データウェアハウスのヒント --- 概要テーブル 。これらは、いくつかのDWプロジェクトで開発したテクニックの多くをまとめたものです。ご推察のとおり、プロジェクトはそれぞれ異なります。 （私の経験では）サマリーテーブルの「典型的な」数は3〜7です。要約のターゲットは、10ファクト行-> 1サマリー行です。 （それは「中央値」かもしれません。）まれなケースで、私は要約表を要約しました。別のまれなケースとして、私はサマリーテーブルを効果的に分割しました。通常、サマリーテーブルは十分に小さいので、UIから直接アクセスできるほど高速です。
まあ、実際には5列以上のPKがあること自体は必ずしも悪いことではありません。
PKがクラスター化インデックスでもあると、行識別子としてカウントされ、NCインデックスの各行に追加されるため、PKが悪くなります。これにより、必要なスペースが大幅に増加します。
現在のテーブルと参照元のテーブルの両方に5つ以上のすべての列のデータが必要なため、実際に別のFKでPKを使用すると、それも悪いことになります。もう一度それは大幅にストレージを増やします！
PKがインデックスとして使用されると、パフォーマンスの面で問題が発生します。テーブル内のみまたはFKと組み合わせて使用すると、5つ以上の列を含む大きなPKキーはより多くのスペースを使用するため、エントリが少なくなります。ページ内に収まるため、インデックスを分析するために、さらに多くのページを読み取る必要があります。
とはいえ、とにかく実際にそうすることには常に正当な理由があるかもしれません。ファクトテーブル。したがって、最良の答えは実際にはほとんどの場合と同じです。
よろしくデニス