21

この 2007 年のホワイト ペーパーでは、クラスター化インデックスとして編成されたテーブルと、CI と同じキー列に非クラスター化インデックスを使用してヒープとして編成されたテーブルでの個々の select/insert/delete/update および range select ステートメントのパフォーマンスを比較しています。テーブル。

一般に、クラスター化インデックス オプションは、維持する構造が 1 つしかなく、ブックマーク ルックアップの必要がないため、テストでより優れたパフォーマンスを示しました。

このホワイト ペーパーで取り上げられていない、潜在的に興味深いケースの 1 つは、ヒープ上の非クラスター化インデックスとクラスター化インデックス上の非クラスター化インデックスの比較です。その場合、NCI リーフ レベルで SQL Server がクラスター化インデックスをトラバースするのではなく、直接追跡する RID を持っているため、ヒープのパフォーマンスがさらに向上することを期待していました。

この分野で実施された同様の正式なテストを知っている人はいますか?もしそうなら、結果はどうでしたか?

4

2 に答える 2

34

あなたのリクエストをチェックするために、私はこのスキームに従って2つのテーブルを作成しました:

  • 残高情報を表す790万レコード。
  • 1から790万まで数えるアイデンティティフィールド
  • レコードを約50万のグループにグループ化する数値フィールド。

呼び出された最初のテーブルはheap、フィールドに非クラスター化インデックスを取得しましたgroup。呼び出された2番目のテーブルは、呼び出さclustれたシーケンシャルフィールドのクラスター化インデックスとフィールドの非クラスター化インデックスを取得しましkeygroup

テストは、2つのハイパースレッドコア、4Gbメモリ、64ビットWindows7を搭載したI5M540プロセッサで実行されました。

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)  

2011年3月9日の更新:次の.netコードを実行し、SQL Server Profilerで期間、CPU、読み取り、書き込み、およびRowCountsをログに記録することにより、2番目に広範なベンチマークを実行しました。(使用されたCommandTextは結果に記載されます。)

注: CPUと期間はミリ秒で表されます

  • 1000クエリ
  • ゼロのCPUクエリが結果から除外されます
  • 影響を受ける0行は結果から除外されます
int[] idList = new int[] { 6816588, 7086702, 6498815 ... }; // 1000 values here.
using (var conn = new SqlConnection(@"Data Source=myserver;Initial Catalog=mydb;Integrated Security=SSPI;"))
            {
                conn.Open();
                using (var cmd = new SqlCommand())
                {
                    cmd.Connection = conn;
                    cmd.CommandType = CommandType.Text;
                    cmd.CommandText = "select * from heap where common_key between @id and @id+1000"; 
                    cmd.Parameters.Add("@id", SqlDbType.Int);
                    cmd.Prepare();
                    foreach (int id in idList)
                    {
                        cmd.Parameters[0].Value = id;

                        using (var reader = cmd.ExecuteReader())
                        {
                            int count = 0;
                            while (reader.Read())
                            {
                                count++;
                            }
                            Console.WriteLine(String.Format("key: {0} => {1} rows", id, count));
                        }
                    }
                }
            }

2011年3月9日の更新の終了

SELECTパフォーマンス

パフォーマンス番号を確認するために、ヒープテーブルで1回、クラストテーブルで1回、次のクエリを実行しました。

select * from heap/clust where group between 5678910 and 5679410
select * from heap/clust where group between 6234567 and 6234967
select * from heap/clust where group between 6455429 and 6455729
select * from heap/clust where group between 6655429 and 6655729
select * from heap/clust where group between 6955429 and 6955729
select * from heap/clust where group between 7195542 and 7155729

このベンチマークの結果は次のheapとおりです。

rows  reads CPU   Elapsed 
----- ----- ----- --------
1503  1510  31ms  309ms
401   405   15ms  283ms
2700  2709  0ms   472ms
0     3     0ms   30ms
2953  2962  32ms  257ms
0     0     0ms   0ms

2011年3月9日の更新cmd.CommandText = "select * from heap where group between @id and @id+1000";

  • 721行のCPUは0を超え、0を超える行に影響します
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1001      69788    6368         -         
Cpu            15        374      37   0.00754
Reads        1069      91459    7682   1.20155
Writes          0          0       0   0.00000
Duration   0.3716   282.4850 10.3672   0.00180

2011年3月9日の更新の終了


clustの結果は次のとおりです。

rows  reads CPU   Elapsed 
----- ----- ----- --------
1503  4827  31ms  327ms
401   1241  0ms   242ms
2700  8372  0ms   410ms
0     3     0ms   0ms
2953  9060  47ms  213ms
0     0     0ms   0ms

2011年3月9日の更新cmd.CommandText = "select * from clust where group between @id and @id+1000";

  • 721行のCPUは0を超え、0を超える行に影響します
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1001      69788    6056         -
Cpu            15        468      38   0.00782
Reads        3194     227018   20457   3.37618
Writes          0          0       0       0.0
Duration   0.3949   159.6223 11.5699   0.00214

2011年3月9日の更新の終了


SELECTWITHJOINパフォーマンス

cmd.CommandText = "select * from heap/clust h join keys k on h.group = k.group where h.group between @id and @id+1000";


このベンチマークの結果は次のheapとおりです。

873行のCPUが0を超え、0を超える行に影響します

Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1009       4170    1683         -
Cpu            15         47      18   0.01175
Reads        2145       5518    2867   1.79246
Writes          0          0       0   0.00000
Duration   0.8215   131.9583  1.9095   0.00123

このベンチマークの結果は次のclustとおりです。

865行のCPUは0を超え、0を超える行に影響します

Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1000       4143    1685         -
Cpu            15         47      18   0.01193
Reads        5320      18690    8237   4.97813
Writes          0          0       0   0.00000
Duration   0.9699    20.3217  1.7934   0.00109

UPDATEパフォーマンス

クエリの2番目のバッチはupdateステートメントです。

update heap/clust set amount = amount + 0 where group between 5678910 and 5679410
update heap/clust set amount = amount + 0 where group between 6234567 and 6234967
update heap/clust set amount = amount + 0 where group between 6455429 and 6455729
update heap/clust set amount = amount + 0 where group between 6655429 and 6655729
update heap/clust set amount = amount + 0 where group between 6955429 and 6955729
update heap/clust set amount = amount + 0 where group between 7195542 and 7155729

このベンチマークの結果heap

rows  reads CPU   Elapsed 
----- ----- ----- -------- 
1503  3013  31ms  175ms
401   806   0ms   22ms
2700  5409  47ms  100ms
0     3     0ms   0ms
2953  5915  31ms  88ms
0     0     0ms   0ms

2011年3月9日の更新cmd.CommandText = "update heap set amount = amount + @id where group between @id and @id+1000";

  • 811行のCPUは0を超え、0を超える行に影響します
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1001      69788    5598       811         
Cpu            15        873      56   0.01199
Reads        2080     167593   11809   2.11217
Writes          0       1687     121   0.02170
Duration   0.6705   514.5347 17.2041   0.00344

2011年3月9日の更新の終了


このベンチマークの結果clust

rows  reads CPU   Elapsed 
----- ----- ----- -------- 
1503  9126  16ms  35ms
401   2444  0ms   4ms
2700  16385 31ms  54ms
0     3     0ms   0ms 
2953  17919 31ms  35ms
0     0     0ms   0ms

2011年3月9日の更新cmd.CommandText = "update clust set amount = amount + @id where group between @id and @id+1000";

  • 853行のCPUは0を超え、0を超える行に影響します
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1001      69788    5420         -
Cpu            15        594      50   0.01073
Reads        6226     432237   33597   6.20450
Writes          0       1730     110   0.01971
Duration   0.9134   193.7685  8.2919   0.00155

2011年3月9日の更新の終了


ベンチマークを削除する

私が実行したクエリの3番目のバッチはdeleteステートメントです

delete heap/clust where group between 5678910 and 5679410
delete heap/clust where group between 6234567 and 6234967
delete heap/clust where group between 6455429 and 6455729
delete heap/clust where group between 6655429 and 6655729
delete heap/clust where group between 6955429 and 6955729
delete heap/clust where group between 7195542 and 7155729

heap:のこのベンチマークの結果

rows  reads CPU   Elapsed 
----- ----- ----- -------- 
1503  10630 62ms  179ms
401   2838  0ms   26ms
2700  19077 47ms  87ms
0     4     0ms   0ms
2953  20865 62ms  196ms
0     4     0ms   9ms

2011年3月9日の更新cmd.CommandText = "delete heap where group between @id and @id+1000";

  • 724行のCPUは0を超え、0を超える行に影響します
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts     192      69788    4781         -
Cpu            15        499      45   0.01247
Reads         841     307958   20987   4.37880
Writes          2       1819     127   0.02648
Duration   0.3775  1534.3383 17.2412   0.00349

2011年3月9日の更新の終了


clust:のこのベンチマークの結果

rows  reads CPU   Elapsed 
----- ----- ----- -------- 
1503  9228  16ms  55ms
401   3681  0ms   50ms
2700  24644 46ms  79ms
0     3     0ms   0ms
2953  26955 47ms  92ms
0     3     0ms   0ms

2011年3月9日の更新

cmd.CommandText = "delete clust where group between @id and @id+1000";

  • 751行のCPUは0を超え、0を超える行に影響します
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts     144      69788    4648         -
Cpu            15        764      56   0.01538
Reads         989     458467   30207   6.48490
Writes          2       1830     127   0.02694
Duration   0.2938  2512.1968 24.3714   0.00555

2011年3月9日の更新の終了


ベンチマークを挿入

ベンチマークの最後の部分は、挿入ステートメントの実行です。

ヒープ/クラストに挿入(...)値(...)、(...)、(...)、(...)、(...)、(...)


heap:のこのベンチマークの結果

rows  reads CPU   Elapsed 
----- ----- ----- -------- 
6     38    0ms   31ms

2011年3月9日の更新

string str = @"insert into heap (group, currency, year, period, domain_id, mtdAmount, mtdAmount, ytdAmount, amount, ytd_restated, restated, auditDate, auditUser)
                    values";

                    for (int x = 0; x < 999; x++)
                    {
                        str += string.Format(@"(@id + {0}, 'EUR', 2012, 2, 0, 100, 100, 1000 + @id,1000, 1000,1000, current_timestamp, 'test'),  ", x);
                    }
                    str += string.Format(@"(@id, 'CAD', 2012, 2, 0, 100, 100, 1000 + @id,1000, 1000,1000, current_timestamp, 'test') ", 1000);

                    cmd.CommandText = str;
  • 912ステートメントのCPUは0を超えています
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1000       1000    1000         -
Cpu            15       2138      25   0.02500
Reads        5212       7069    6328   6.32837
Writes         16         34      22   0.02222
Duration   1.6336   293.2132  4.4009   0.00440

2011年3月9日の更新の終了


clust:のこのベンチマークの結果

rows  reads CPU   Elapsed 
----- ----- ----- -------- 
6     50    0ms   18ms

2011年3月9日の更新

string str = @"insert into clust (group, currency, year, period, domain_id, mtdAmount, mtdAmount, ytdAmount, amount, ytd_restated, restated, auditDate, auditUser)
                    values";

                    for (int x = 0; x < 999; x++)
                    {
                        str += string.Format(@"(@id + {0}, 'EUR', 2012, 2, 0, 100, 100, 1000 + @id,1000, 1000,1000, current_timestamp, 'test'),  ", x);
                    }
                    str += string.Format(@"(@id, 'CAD', 2012, 2, 0, 100, 100, 1000 + @id,1000, 1000,1000, current_timestamp, 'test') ", 1000);

                    cmd.CommandText = str;
  • 946ステートメントのCPUは0を超えています
Counter   Minimum    Maximum Average  Weighted
--------- ------- ---------- ------- ---------
RowCounts    1000       1000    1000         -      
Cpu            15       2403      21   0.02157
Reads        6810       8997    8412   8.41223
Writes         16         25      19   0.01942
Duration   1.5375   268.2571  6.1463   0.00614

2011年3月9日の更新の終了


結論

クラスター化インデックスと非クラスター化インデックスを使用してテーブルにアクセスすると(非クラスター化インデックスを使用している間)、より多くの論理読み取りが実行されますが、パフォーマンスの結果は次のとおりです。

  • SELECTステートメントは同等です
  • クラスター化されたインデックスを配置すると、UPDATEステートメントが高速になります
  • クラスタ化されたインデックスを配置すると、DELETEステートメントが高速になります
  • INSERTステートメントは、クラスター化インデックスを配置すると高速になります

もちろん、私のベンチマークは特定の種類のテーブルと非常に限られたクエリのセットに非常に限定されていましたが、この情報に基づいて、テーブルにクラスター化されたインデックスを作成する方が事実上常に優れているとすでに言えます。

2011年3月9日の更新

追加された結果からわかるように、限定されたテストの結論はすべての場合に正しくありませんでした。

加重期間

結果は、クラスター化されたインデックスの恩恵を受けるステートメントは更新ステートメントのみであることを示しています。他のステートメントは、クラスター化されたインデックスを持つテーブルでは約30%遅くなります。

ヒープとクラストのクエリごとの加重期間をプロットしたいくつかの追加のグラフ。 Selectの加重期間ヒープとクラスター化

加重期間ヒープと結合用のクラスター化

加重期間ヒープと更新用のクラスター化

加重期間ヒープと削除用のクラスター化

ご覧のとおり、挿入ステートメントのパフォーマンスプロファイルは非常に興味深いものです。スパイクは、完了するのにはるかに長い時間がかかるいくつかのデータポイントによって引き起こされます。 加重期間ヒープと挿入用のクラスター化

2011年3月9日の更新の終了

于 2011-03-04T22:57:50.923 に答える
11

Kimberly Tripp(インデックス作成の女王)が彼女のブログ投稿で非常にうまく説明しているように、クラスター化インデックスの議論は続きます...データベーステーブルにクラスタリングキーがあると、すべての操作が大幅に高速化されますSELECT

SELECTは、適切なクラスタリングキー(のようなもの)を選択する限り、一般に、クラスター化されたテーブルと比較してヒープ上で遅くなりますINT IDENTITY。GUIDや可変長コンポーネントが多数ある複合キーなど、非常に悪いクラスタリングキーを使用する場合は、ヒープの方が高速になる可能性があります。しかし、その場合、最初にデータベース設計をクリーンアップする必要があります...

したがって、一般的に、ヒープには何の意味もないと思います。優れた有用なクラスタリングキーを選択すれば、あらゆる点でメリットが得られるはずです。

于 2011-02-23T17:50:14.763 に答える