0

実行中: SQL Server 2008 R2 Standard。これは、SQL Server だけでなく、すべてのデータベースに関する質問だと思いますが。

背景:私は常に、インデックスの最先端は非常に選択的であるべきだと聞いたり、読んだり、言われたりしてきました。これは、特定の値または値の小さなセット (製品 ID など) を求めるクエリがある場合に意味があります。

一般的な質問:高度に選択的でないインデックスが役立つ場合はありますか?

例: 3 億 5000 万行のテーブルがあります。テーブルには一連の価格が含まれています。テーブルには次の列があります。

  • priceId-- テーブルのクラスタ化インデックス
  • warehouseId-- 150m の列に均等に分散された 10 の倉庫の 1 つに fk
  • algorithmId-- 1 億 5000 万行に均等に配分された、価格の計算方法に関する 23 のアルゴリズムの 1 つに fk
  • priceDate-- 最後に価格を計算した日付
  • productId

次に、次のクエリを実行します。

select productId 
from price 
where warehouseId = 1 
    and algorithmId = 1 
order by priceDate

具体的な質問: このようなインデックスは役に立ちませんか?

create nonclustered index ix_p 
on price (warehouseId, algorithmId, priceDate) includes (productId)

SQL Server が一度に巨大なチャンクを切り出し、priceDate. それは理にかなっていますか？そして、それは機能しますか？

注：これを試してみて、見つけたものをお知らせします。

4

2 に答える 2

0

簡単な答え - はい。ただし、基本的にはストレージが 2 倍になりました。

長い答え:

1 億 5000 万行のデータを持つ SQL 2012 VirtualBox Server 2008 VM でこれをテストしました。ファイル グループは、ソリッド ステート ドライブへの USB 3.0 接続上にある VM イメージに格納されました (順次読み取りは約 250 mb/s、書き込みは約 150 mb/s のようです)。

疑似ランダムな日付と productIds、1 ～ 10 の Warehouseid、および 1 ～ 23 のアルゴリズム ID が均等に分散されたテーブルを作成しました。(基本的に、データをロードする SSIS でソース スクリプト コンポーネントを作成しました)。

テーブル ストレージ スペースは約 4.7 GB で、主キー priceid にクラスター化インデックスがありました。

このクエリの実行:

select productId 
from price 
where warehouseId = 1 
    and algorithmId = 1 
order by priceDate

約 30 秒で約 100 万行が返されました。Plan は、クラスター化されたインデックス スキャンと並べ替え (priceDate 順) を示します。

次に、この非クラスター化インデックスを追加しました。

create nonclustered index ix_p 
on price (warehouseId, algorithmId, priceDate) include (productId)

このインデックスは、テーブルとほぼ同じ大きさ (約 4.3 GB) です。

非クラスター化インデックスを追加すると、priceDate の SORT ステップがなくなり、データにアクセスするために非クラスター化インデックス シークを実行するように変更されました。このインデックスの作成には 11 分以上かかりました。

同じクエリ: 約 4 秒で最大 100 万行が返されます。Plan は、非クラスター化インデックス シークを示します。

これが行っている最大のことは、基本的にデータの 2 つのコピーを作成することだと思います。1 つはクラスター化インデックス構造で、もう 1 つは「非クラスター化」構造です。

挿入ごとに基本的に2行を作成する必要があるため、挿入には約2倍の時間がかかると予想されます。

このテーブルを定期的に更新していますか? 他にも役立つ戦略があるかもしれません。

于 2013-11-08T19:29:27.783 に答える