次のようなテーブル構造があります。
人
Id
個人の人口統計
Id
PersonId
はPerson > PersonDemographic1 対 1 の関係であり、 の一意の制約によってそのように強制されますPersonDemogrphic.PersonId。
この構造は、この特定のデータベースに浸透しています。その結果、Person から個人の詳細を含むテーブルへの結合は、ハッシュ マッチとテーブル スキャンで構成されます。
クエリを最適化するために、(テーブル ID ではなく) 個人 ID をクラスター化された主キーにしようとしました。これにより、ネストされたループとクラスター化されたインデックス スキャンが発生しました (そしてパフォーマンスがわずかに向上しました)。
FORCESEEK1 対 1 の関係であることを知っていたので、結合にヒントを与えることでパフォーマンスを改善できるのではないかと考えました。しかし、それはそれを悪化させました。実行計画の統計に基づいて、「逆の関係」テーブルでのクラスター化インデックス シークは、実行回数が推定される「通常は関連する」テーブルの実行とは対照的に、行ごとに 1 回演算子を実行しているように見えます。 1.
このシナリオに最適な実行計画を得るための提案を探しています。「テーブル構造を修正する」が有効であり、おそらく最良の答えであると認識していますが、現時点ではそれを避けたいと考えています。
ありがとう！