Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

This 2007 White Paper compares the performance for individual select/insert/delete/update and range select statements on a table organized as a clustered index vs that on a table organized as a heap with a non clustered index on the same key columns as the CI table.

Generally the clustered index option performed better in the tests as there is only one structure to maintain and because there is no need for bookmark lookups.

One potentially interesting case not covered by the paper would have been a comparison between a non clustered index on a heap vs a non clustered index on a clustered index. In that instance I would have expected the heap might even perform better as once at the NCI leaf level SQL Server has a RID to follow directly rather than needing to traverse the clustered index.

Is anyone aware of similar formal testing that has been carried out in this area and if so what were the results?

share|improve this question

migrated from stackoverflow.com Dec 28 '11 at 12:25

This question came from our site for professional and enthusiast programmers.

    
I've added a bounty to this question to see if it attracts more relevant answers. Note the question is about one very specific aspect not a general question as to whether CIs are better than heaps. NB: I also realise that the relative performance between CIs and heaps in this area will doubtless depend on specifics such as depth of CI and probably a load of other things which is why I'm hoping to find the results of someone else's testing. –  Martin Smith Mar 3 '11 at 13:37
    
...Or to put it another way I'm asking about the performance impact (of any) of using a logical RID rather than a phsical RID. –  Martin Smith Mar 8 '11 at 15:54
add comment

3 Answers 3

up vote 32 down vote accepted

To check your request I created 2 tables following this scheme:

  • 7.9 million records representing balance information.
  • an identity field counting from 1 to 7.9 million
  • a number field grouping the records in about 500k groups.

The first table called heap got a non clustered index on the field group. The second table called clust got a clustered index on the sequential field called key and a nonclustered index on the field group

The tests were run on an I5 M540 processor with 2 hyperthreaded cores, 4Gb memory and 64-bit windows 7.

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)  

Update on 9 Mar 2011: I did a second more extensive benchmark by running the following .net code and logging Duration, CPU, Reads, Writes and RowCounts in Sql Server Profiler. (The CommandText used will be mentioned in the results.)

NOTE: CPU and Duration are expressed in milliseconds

  • 1000 queries
  • zero CPU queries are eliminated from the results
  • 0 rows affected are eliminated from the results
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));
                        }
                    }
                }
            }

End of Update on 9 Mar 2011.

SELECT performance

To check performanc numbers I performed the following queries once on the heap table and once on the clust table:

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

The results of this benchmark are for the 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

Update on 9 Mar 2011: cmd.CommandText = "select * from heap where group between @id and @id+1000";

  • 721 Rows have > 0 CPU and affect more than 0 rows
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

End of Update on 9 Mar 2011.


for the table clust the results are:

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

Update on 9 Mar 2011: cmd.CommandText = "select * from clust where group between @id and @id+1000";

  • 721 Rows have > 0 CPU and affect more than 0 rows
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

End of Update on 9 Mar 2011.


SELECT WITH JOIN performance

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


The results of this benchmark are for the heap:

873 Rows have > 0 CPU and affect more than 0 rows

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

The results of this benchmark are for the clust:

865 Rows have > 0 CPU and affect more than 0 rows

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 performance

The second batch of queries are update statements:

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

the results of this benchmark for the 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

Update on 9 Mar 2011: cmd.CommandText = "update heap set amount = amount + @id where group between @id and @id+1000";

  • 811 Rows have > 0 CPU and affect more than 0 rows
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

End of Update on 9 Mar 2011.


the results of this benchmark for the 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

Update on 9 Mar 2011: cmd.CommandText = "update clust set amount = amount + @id where group between @id and @id+1000";

  • 853 Rows have > 0 CPU and affect more than 0 rows
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

End of Update on 9 Mar 2011.


DELETE benchmarks

the third batch of queries I ran are delete statements

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

The result of this benchmark for the 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

Update on 9 Mar 2011: cmd.CommandText = "delete heap where group between @id and @id+1000";

  • 724 Rows have > 0 CPU and affect more than 0 rows
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

End of Update on 9 Mar 2011.


the result of this benchmark for the 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

Update on 9 Mar 2011:

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

  • 751 Rows have > 0 CPU and affect more than 0 rows
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

End of Update on 9 Mar 2011.


INSERT benchmarks

The last part of the benchmark is the execution of insert statements.

insert into heap/clust (...) values (...), (...), (...), (...), (...), (...)


The result of this benchmark for the heap:

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

Update on 9 Mar 2011:

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 statements have > 0 CPU
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

End of Update on 9 Mar 2011.


The result of this benchmark for the clust:

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

Update on 9 Mar 2011:

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 statements have > 0 CPU
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

End of Update on 9 Mar 2011.


Conclusions

Although there are more logical reads going on when accessing the table with the clustered & the nonclustered index (while using the nonclustered index) the performance results are:

  • SELECT statements are comparable
  • UPDATE statements are faster with a clustered index in place
  • DELETE statements are faster with a clustered index in place
  • INSERT statements are faster with a clustered index in place

Of course my benchmark was very limited on a specific kind of table and with a very limited set of queries, but I think that based on this information we can already start saying that it is virtually always better to create a clustered index on your table.

Update on 9 Mar 2011:

As we can see from the added results, the conclusions on the limited tests were not correct in every case.

Weighted Duration

The results now indicate that the only statements which benefit from the clustered index are the update statements. The other statements are about 30% slower on the table with clustered index.

Some additional charts where I plotted the weighted duration per query for heap vs clust. Weighted Duration heap vs clustered for Select

Weighted Duration heap vs clustered for Join

Weighted Duration heap vs clustered for Update

Weighted Duration heap vs clustered for Delete

As you can see the performance profile for the insert statements is quite interesting. The spikes are caused by a few data points which take a lot longer to complete. Weighted Duration heap vs clustered for Insert

End of Update on 9 Mar 2011.

share|improve this answer
    
@Martin I will try to run this on a server with a few tables with 500 million records when I find some time next week. –  Filip De Vos Mar 4 '11 at 22:59
1  
+1 Excellent stuff. Some interesting results. –  Martin Smith Mar 4 '11 at 23:06
    
I doubt the veracity of this test. Some parts need serious attention, such as INSERT performance claiming the clustered index is faster - there were more reads in the CLUST version, but elapsed time is less. I personally would have ignored the elapsed time being within 10s of milliseconds (timing variability) - it means less than the read count. –  Richard aka cyberkiwi Mar 8 '11 at 21:18
1  
@Martin, @Richard, @marc_s . I am working on a more serious benchmark right now. I hope to be able to add the results later today. –  Filip De Vos Mar 9 '11 at 20:05
1  
@Filip - Wow! You definitely deserve the bounty for all the hard work you have put into this answer. Though as you quite rightly point out this was one benchmark on a specific kind of table with a very limited set of queries and mileage will doubtless vary. –  Martin Smith Mar 10 '11 at 12:52
show 5 more comments

As Kimberly Tripp - the Queen of Indexing - explains quite nicely in her blog post The Clustered Index Debate continues..., having a clustering key on a database table pretty much speeds up all operations - not just SELECT.

SELECT are generally slower on a heap as compared to a clustered table, as long as you pick a good clustering key - something like an INT IDENTITY. If you use a really really bad clustering key, like a GUID or a compound key with lots of variable length components, then, but only then, a heap might be faster. But in that case, you really need to clean up your database design in the first place...

So in general, I don't think there's any point in a heap - pick a good, useful clustering key and you should benefit in all respects.

share|improve this answer
2  
This is a non-answer. Martin is pretty solid on SQL Server; the question was intended to get real world tested verified results from performance testing, not more theory. –  Richard aka cyberkiwi Mar 9 '11 at 19:11
    
The Kimberly Tripp article linked effectively assumes all nonclustered indexes are covering. If that's the case, then there would be no lookups, and the heap's advantage in lookups would be negated. That's not a world most of us live in, though. In our cases, trying to design all or most of our nonclustered indexes to cover creates problems of its own. –  user31683 Dec 13 '13 at 18:08
    
@dbaguy52: why do you think Kim Tripp assumes all NC indexes are covering? I don't see any notion of that in her blog post ..... please explain in more detail what makes you believe that's the case (or that's her assumption) –  marc_s Dec 13 '13 at 19:43
add comment

Just happened to come across this article from Joe Chang that addresses this question. Pasted his conclusions below.

Consider a table for which the indexes have depth 4, so that there is a root level, 2 intermediate levels and the leaf level. The index seek for a single index key (that is, no key lookup) would generate 4 logical IO (LIO). Now consider if a key lookup is required. If the table has a clustered index also of depth 4, each key lookup generates 4 LIO. If the table were a heap, each key lookup generates 1 LIO. In actuality, the key lookup to a heap is about 20-30% less expensive than a key lookup to a clustered index, not anywhere close to the 4:1 LIO ratio.

share|improve this answer
    
Interesting thing to note is that the quote from Joe Chang identified an efficiency advantage of 20-30% for heaps based on his assumptions which is pretty much the same advantage identified in the March 9 update to the article. –  user31683 Dec 13 '13 at 18:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.