2

最近、ある同僚が、データベースを再構築する計画について説明してくれました。新しいデータベースは単純なスター スキーマに準拠します。親テーブルはキーといくつかのコンテキスト情報で構成され、そのキーは他のテーブルの外部キー フィールドとして機能します。外部キー フィールドは、同じ子テーブルに複数回表示される場合があります。

擬似コード:

TABLE Parent
   INT key PRIMARY_KEY
   INT foo
   ...

TABLE Child1
   INT key FOREIGN_KEY REFERENCES Parent.key
   BLOB bar
   ...

TABLE Child2
   INT key FOREIGN_KEY REFERENCES Parent.key 
   VARCHAR tar
   ...

この設計の背後にある動機は、以前のスキーマでは複雑だった と のParent間の JOIN を単純化することです。Child<n>

JOIN をさらに高速化するために、同僚は OUTER JOIN の使用を最小限に抑えたいと考えています。key具体的にはParent、JOINS を使用し、特定の方法で子テーブルのデータを維持することにより、OUTER JOIN をエミュレートしたいと考えてChild<n>いkeyます。それ以外の場合は s でいっぱいですnull。このように、 と の間Parentで実行Child<n>される JOIN は、すべての inkeyに対して少なくとも 1 つの結果を返します。keyParent

この方法でデータを維持することに努力する価値があるかどうかという問題はさておき、すべてのkeyフィールドに適切にインデックスが付けられ、子の行の約半分が削除されていると仮定すると、このアプローチは OUTER JOINS を実行するよりもパフォーマンスが高いnullでしょうか?

質問は、「インデックスに存在しない値よりも、インデックスに存在する値のインデックス ルックアップを実行する方が高速ですか?」に要約されるようです。インデックスが B ツリーまたはハッシュのように機能すると仮定すると、答えは「いいえ」と思いますが、確信を持てるだけのことはわかりません。

4

2 に答える 2

2

個人的には、外部結合と内部結合のパフォーマンスの大きな違いに気付いていません。なぜあなたの同僚は自分の方が遅いと信じているのですか?

レコードを追加すると、パフォーマンスに 2 つの影響があります。元のデータが大きくなり、データを格納するためにより多くのページが必要になります。これは、パフォーマンスに大きな影響を与える可能性があります。特に、追加のページ (有用なデータを持たない) が、より有用な構造 (インデックスなど) とスペースを競合している場合はそうです。

2 番目の効果はインデックスです。サイズを大きくする必要があるため、インデックスが深くなり、インデックス ページが増える可能性があります。これらは両方とも、パフォーマンスに影響を与える可能性があります。

パフォーマンスに関係のない別の問題もあります。クエリを作成するユーザー/開発者は、これらの空のレコードが存在することを完全に理解する必要があります。COUNT(*) または COUNT() を実行して、結果がデータを含むレコードの数を正確に反映することを期待するのは非常に簡単です。そうでない場合は、後でコーディングの問題が発生する可能性があります。

于 2012-09-12T22:05:41.950 に答える
1

この方法でパフォーマンスが向上するとは思いません。

通常、内部結合は外部結合よりも高速です。これは、内部結合がより制限的であり、オプティマイザーが計画の早い段階で結果セットを削減する機会を多く与えるためです。

しかし、人為的にデータを追加すると、内部結合はもはや制限的ではなくなります。

于 2012-09-13T07:15:57.810 に答える