web-dev-qa-db-ja.com

キールックアップパーティションプルーニング

複数のテーブルを結合するクエリ内部があり、そのすべてがパーティション化されており、それぞれに10個のパーティションがあります。

SELECT A.COL1, B.COL2, C.COL3
FROM A 
INNER JOIN B ON A.ID = B.ID
INNER JOIN C ON A.ID = C.ID 
WHERE COL20 < 10000  ---- COL20 IS NOT THE PARTITION KEY COLUMN

実際のクエリ実行プランでは、テーブルの1つに対して、キールックアップを使用した非クラスター化インデックススキャンがあります。

実際の実行プランでキールックアップのプロパティを見ると、パーティションがプルーニングされているように見えます。

なぜそうなるのか混乱していますが、これはシステムへの悪影響のようなものです。キールックアップ自体が悪いことは理解していますが、7つのパーティションしかアクセスされていないことが表示されるのはなぜですか？プロパティは言う：

Key Lookup (Clustered)
----------------------------------
Actual number of rows:      215805
Actual Partition Count:     7
Actual Partitions Accessed: 3..9

私の懸念は、ルックアップがどのように機能するかについてです。パーティショニングがない場合、ルックアップが特定のキーのデータページからデータをフェッチするときに、このページに到達するためにシークまたはスキャンを実行しますか？直接キールックアップは、パーティションプルーニングを使用したキールックアップよりもパフォーマンスが優れていますか？

sql-serversql-server-2008partitioningbookmark-lookup
1
Amam

7つのパーティションの行のみが述部を修飾するため、他の3つのパーティションの行を検索する必要はありません。

クエリプランは、Bでスキャンし、Aでプローブ（ルックアップ）することを選択できます。

キールックアップは常にクラスター化されたインデックスへのシークです。ちなみに、元の例ではパーティションの削除はありません。クエリプロセッサは、クエリの実行中に7つの異なるパーティション（3..9）にアクセスしたことを報告しているだけです。どのルックアップも他のパーティションにアクセスしませんでした。

1
Remus Rusanu