次のクエリは、行数と注文の数を返します。一部のスター結合クエリでは、その効果はもっと大きくなります。フィルターも使用されます。フィルターにより、結合が実行される前に、含まれる行の数を削減し、結合演算子で処理する行の数を減らすことで、クエリの実行速度を向上します。チェックはハッシュ結合のプローブ側で実行されます。フィルターの使用状況を調べることができます。インデックスを含むテーブルは更新できません。つの方法で回避できます。インデックスを再構築します。テーブルをパーティション分割して、パーティションを切り替えます。テーブルを空のパーティションに切り替えます。インデックスを無効にするか削除し、更新操作を実行します。テーブルに格納します。インデックスを含まず、スキーマが同じである別のテーブルに格納します。最新のデータを含むテーブルに更新を適用します。つの結果セットを結合します。インデックスの効果が得られます。インデックスがなくてもパフォーマンスに悪影響が及ぶことはありません。あるビューに対してクエリを実行することもできますが、パフォーマンス上の利点が小さくなる可能性があります。プランに左右されます。プランはクエリ、データ、および基数の推定値の影響を受けます。インデックスが含まれないテーブルに更新を迂回できることと、ユーザーやアプリケーションがビューのメカニズムを把握できることです。使用するどちらかの手法を使用する場合、一般的なクエリに対するパフォーマンスをテストし、パフォーマンス向上の効果が減少するデメリットよりもこの手法を使用するメリットの方が大きいかどうかを判断してください。インデックスを作成しないでください。インデックスを含むテーブルの更新に関する制限事項は、将来のリリースでは保証されていません。読み取り専用の動作が必要な場合は、読み取り専用ファイルグループを作成して、テーブルをそのファイルグループに移動してください。ページの数を減らす圧縮機能によって得られます。圧縮機能は、重複した値が大量に含まれる文字型列や数値型列に対して使用した場合に最も効率が高くなります。販売地域の列が含まれているとします。各市区町村に多数の郵便番号があり、さらに各販売地域に多数の市区町村がある場合、販売地域の列の圧縮率が最も高くなります。市区町村の列はそれよりも圧縮率が低く、郵便番号の列の圧縮率が最も低くなります。インデックスを追加することで列ストア圧縮の効果を最大にすることができます。郵便番号の列を追加した場合、その効果は最も小さくなります。ウェアハウスのシナリオでクエリをサポートするために開発されました。インデックスを含むテーブルのデータを定期的に更新する必要がある場合に、パーティション分割をお勧めします。インデックスのデータの更新」を参照してください。インデックスの作成は、一般的なインデックスの作成と似ています。ステートメントを実行します。テーブルの作成」を参照してください。(Transact-SQL)」を参照してください。エンジンのインスタンスに接続します。