大規模なパーティションOLAPテーブルを管理する特権があります。この表を確認したところ、インデックスの1つがパーティションスキームと一致していないことに気付きました。著者が利用できず、注意深く作成されたGoogle検索で有用な結果が返されなかったため、これが意図的なものか偶発的なものかはわかりません。
SQL Server 2008でインデックスをパーティションアラインしない理由はありますか?
大規模なパーティションOLAPテーブルを管理する特権があります。この表を確認したところ、インデックスの1つがパーティションスキームと一致していないことに気付きました。著者が利用できず、注意深く作成されたGoogle検索で有用な結果が返されなかったため、これが意図的なものか偶発的なものかはわかりません。
SQL Server 2008でインデックスをパーティションアラインしない理由はありますか?
回答:
パーティションベースオブジェクトの(一意でない)インデックスを分割しないの主な利点は、それが周りに動作することで長年のクエリオプティマイザの制限などの順序付けられたデータ要求に関連するMIN
、MAX
またはTOP (n)
クエリ。
パーティション化されたインデックスでは、オプティマイザは通常MIN
、パーティションごとに同じ操作に変換したりMAX
、変換したりできません。その後に、パーティションごとの部分集計に対する最終的なグローバル集計が続きます。オプティマイザは代わりに、インデックスのすべてのパーティションをスキャンする実行プランを選択します。これの例外は、集計または最上位の操作がパーティション列に対して指定されている単一のケースです。TOP (n)
整列されていないインデックスを使用しない非常に良い理由もあることに言及する必要があります。非境界整列インデックスを使用することを選択することは、非常に情報に基づいた選択でなければなりません。私は過去に(まれに)自分でそれを実行しましたが、利益が明らかにコストを上回るか、他の合理的な代替手段がなかった非常に特殊な状況で。
問題を説明するItzik Ben-Ganによる記事。
非整列索引を必要とするいくつかの制約(例えば、固有)の周りに明らかな問題があります。
それ以外は、アラインされていないインデックスには大きなコストがかかります(主に、多くの並列演算子がパーティションごとにスレッドを実行することを防ぎ、代替案はメモリに負荷がかかります)。Paulによってリストされたケースがあったとしても、私はまだ非整列インデックスに対して助言します。
非整列インデックスは、パーティションの切り替えであるパーティション分割の主な利点を打ち消します。これに依存せず、他の理由(別のストレージ、読み取り専用パーティション、増分統計など)でパーティション分割している場合は、調整されていないindexexを作成してください。
非整列インデックスは、テーブル全体に一意の制約を適用できるため便利です。また、非境界整列インデックスでは、パーティション化キーを暗黙的なシークプレフィックスにする必要はありません。10000のパーティションがあり、パーティションキーに基づいていないクエリを想像してください。実行プランは、インデックスが調整されている場合、10000のパーティションにシークする必要があります。他の答えには、さらなる例があります。