そのうちの 2 つに約 100 万件のレコードがあるテーブルがいくつかあります。ある手順でこれらのテーブルを使用していますが、約 25,000 行を取得するのに約 5 ～ 10 分かかります。
クラスター化インデックスと非クラスター化インデックスをいくつか作成しましたが、実行計画ではすべてがクラスター化インデックス シークまたは非クラスター化インデックス シークであることが示されています。ただし、手順の実行にはまだ 5 分以上かかります。
だから私は列ストアインデックスを作成しようとしましたが、まだ改善されていません。
みんな、これについて誰かアドバイスしてくれませんか。インデックスを作成する方法と、どちらが優れているか列ストアまたは通常のクラスター化/非クラスター化インデックス
列ストア インデックスが適切かどうかは、テーブル/データベースの目的によって異なります。列ストアは、データ ウェアハウス内の大規模なファクト テーブルで使用するように設計されています。OLTP やその他の運用データベース用には構築されていません。データ ウェアハウスを使用している場合、クラスター化された列ストアは通常は良いアイデアですが、100 万を超える tow 用に設計されていると思いますが、それでも問題なく動作し、圧縮の改善によるメリットも得られるはずです。
OLTP または混合使用の場合は、インデックス作成だけに集中したいでしょう。クエリ プランとstatistics io出力を見て、速度低下の原因を突き止めます。何が問題なのかわからない場合は、投稿を編集するか、テーブル、インデックス、およびクエリ プランの詳細を記載した新しい投稿を依頼してください。
クエリ プランでよく見られるのは、多数の行のインデックス スキャンと並べ替えとキー ルックアップです。100 万行を処理しているため、速度低下の原因となっている一時データベースへのスプールまたはスピルが存在する可能性もあります。