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）（またはいくつかの適切な組み合わせ）。それを行うと、各行は10M行だけになる可能性があり、それによりレポートをさらに高速化すると同時に、レポートの柔軟性もほぼ同じになります。

または、（week、a、b、c、d）に切り替えて、1400万行だけになる場合があります。（おそらくもっと。）

パーティションを使用したプルーニングの促進 --- 高速取り込み --- データウェアハウスのヒント --- 要約表。これらは、私がいくつかのDWプロジェクトで開発したテクニックの多くを要約しています。推測できるように、各プロジェクトは異なります。（私の経験では）サマリーテーブルの「典型的な」数は3〜7です。要約のターゲットは、10行のファクト行-> 1行の要約行です。（それは「中央値」かもしれません。）まれなケースでは、要約表を要約しました。別のまれなケースでは、私は効果的な要約表を分割しました。通常、サマリーテーブルは十分に小さいため、UIから直接アクセスするのに十分高速です。

5列以上のPKを実際に持っていること自体は必ずしも悪いことではありません。

PKがクラスター化インデックスでもあると、行識別子としてカウントされ、NCインデックスの各行に追加されるため、不良になります。これにより、必要なスペースが大幅に増加します。

また、現在のテーブルと参照元テーブルの両方に5+列すべてのデータが必要であるため、別のFKで実際にPKを使用した場合も問題になります。もう一度、ストレージを大幅に増やします！

PKをインデックスとして使用するとパフォーマンスが低下します。テーブル内のみ、またはFKと組み合わせて使用​​します。5列以上の大きなPKキーはより多くのスペースを必要とするため、エントリが少なくなります。ページ内に収まるため、インデックスを分析するには、さらに多くのページを読み込む必要があります。

とはいえ、ファクトテーブルなど、とにかく実際にそうする理由は常にあるかもしれません。したがって、最良の答えは実際にはほとんどの場合と同じです。

よろしくデニス

15年以上の間、私はそのような鍵を必要とせず、時々見ましたが、それはトラブルを引き起こすだけでした。多くのトラブル。まず第一に、主キーはデータの整合性を保持するためのものであり、合成する必要があります。彼らは現実の世界に拘束力を持ってはいけません。どうして ？現実の世界が変わると、確実に主キーがなくなり、更新する必要があります。また、すべての関連情報も更新する必要があります。

いくつかのフィールドをコピーするのではなく、他のテーブル/データベース/サービスでこのカーを覚えておく必要があることを想像してください。コピーするのを忘れることもあります。代わりに、sysntetic主キーは単なるデータの一部であり、提供する必要があります。インデックスの一意性については言及していませんが、これは別の大きなトピックで議論される可能性があります。

つまり、要約すると、合成主キー（自動インクリメント、GUID、..）は、保守、コピー、...が簡単です。

そこで、合成主キーと、あなたが言及した5列の別のキーを検討します。

最後に、テーブルが集計のみであり、誰かがキーで行を参照する必要がまったくない場合（しかし、世界は変化します、少なくとも私にとっては永続的に変化します）、私はおそらくそれをそのままにします（プライマリ5行のキー）が、以前は持っていた場合、常に多くの問題を引き起こします。だから私はあなたに言った。