I got asked this question during one of my TechEd sessions. It was a bit complex to answer there and then, so I answered by mail a few days later, and I thought it would make a good blog post if expanded a bit more.<\/p>\n
Assume a table with 5 columns (imaginatively called A, B, C, D and Z). A and B are ints, C is a datetime and D is a char(50). Let’s assume that Z is an int, identity, primary key and has the clustered index<\/p>\n
If I put an index on A and B, the size of the index key (ignoring headers and other overhead) is 8 bytes. Add in the clustering key for row location and each index leaf record in 12 bytes wide. That means that (at 100% fill factor) there are around 660 index rows per leaf page. Since I’m ignoring headers, this rough calc will not exactly match reality, but it’s close enough.<\/p>\n
If the table has 100000 rows, the the leaf level of the index consists of 152 pages.<\/p>\n
To calculate the number of pages above, one should know that for each leaf page, the next level higher has one index row in – the first value on the page. Hence, for 152 leaf pages, the level above will have 152 index rows as 12 bytes each totalling 1824 bytes. This will fit on one page, so the level above the leaf is the index root, and this index has only two levels.<\/p>\n
To seek a single row from this index hence requires 2 page reads.<\/p>\n
Now, the clustered index has row sizes of around (again ignoring row headers) 70 bytes. At that size, there will be 115 rows per page, for a total of 870 pages. For the level above, only the clustering key needs to be in the pages (4 bytes) along with the page pointer (which is a binary(6)) and 870 index entries are required. At 10 bytes\/row that means that 2 pages are required at this level. That means that there is one more level to the index – the root, making the clustered index a three level index.<\/p>\n
To seek a single row from the clustered index hence requires 3 page reads.<\/p>\n
Let’s take a quick example query.
\nSELECT A,B FROM TestTable WHERE A=2 and B=16
\nLet’s further assume that this returns 100 rows, and that those 100 rows are situated on two neighbouring pages of the nonclustered index (worst case). To completely satisfy this query requires 3 page reads. 2 to find the beginning of the range and a third on the next page (index leaf level have next and previous page pointers). Very fast query, very few IOs.<\/p>\n
Now a second query
\nSELECT A,D FROM TestTable WHERE A=2 and B=16<\/p>\n
The index rows for this query are on the same 100 leaf pages of the nonclustered index. The problem is, the noncluster doesn’t contain D, and so a bookmark\/key lookup is required for each row. 100 key lookups at 3 reads each means that in total this query will take 303 page reads.<\/p>\n
What if we widened the nonclustered index? I’ll put D as an include column.<\/p>\n
Now, the leaf index rows are around 62 bytes in size, meaning that the nonclustered index has\u00a0 130 rows per page and a total of 770 leaf pages.<\/p>\n
The upper level of the index still only requires 12 bytes, and so 770 leaf pages requires 770 index entries at 12 bytes each is 9240 bytes, for a total of 2 pages. This means that another level of the index is required and so this nonclustered index is three levels deep and a single row seek requires 3 reads.<\/p>\n
Back to the two examples.<\/p>\n
SELECT A,B FROM TestTable WHERE A=2 and B=16
\nThis still returns 100 rows and those 100 rows are still across two index leaf pages (again assuming worst case). Now this query requires 4 reads, 3 to find the start of the range and 1 to get the next page<\/p>\n
SELECT A,D FROM TestTable WHERE A=2 and B=16
\nThis also still returns 100 rows and those 100 rows are also still across two index leaf pages. The difference now is that D is contained within the index and so no bookmark\/key lookup is required. This query also requires only 4 page reads, 3 to find the start and 1 to get the next page.<\/p>\n
So, the width of the index rows has more than quadrupled, and the queries that use index seeks only require one more read.<\/p>\n
The theory looks nice, let’s see if reality agrees with it.<\/p>\n
Create Table TestingWideIndexes (
\nA int not null,
\nB int not null,
\nC datetime not null,
\nD char(50) not null,
\nZ int identity primary key — defaults to clustered
\n)
\nGO<\/p>\n
Insert into TestingWideIndexes (A,B,C,D)
\nSELECT ID\/15, FLOOR((RAND(ID*1422)*10)), DATEADD(hh, ID, ‘1990\/01\/01’), ‘x’ FROM (
\nSELECT top 100000 a.number*100+b.number AS ID
\nfrom master..spt_values a cross join master..spt_values b
\nwhere a.name is null and b.name is null) x<\/p>\n
CREATE INDEX Testing_1 ON TestingWideIndexes (A, B)<\/p>\n
SELECT * from sys.dm_db_index_physical_stats(db_id(), object_id(‘TestingWideIndexes’), 4, 0, DEFAULT )
\n— page count 186<\/p>\n
SET STATISTICS IO ON
\nGO<\/p>\n
SELECT A,B FROM TestingWideIndexes WHERE A=180 and B=3
\n— Table ‘TestingWideIndexes’. Scan count 1, logical reads 2
\n— SQL Server Execution Times:
\n—\u00a0\u00a0 CPU time = 0 ms,\u00a0 elapsed time = 0 ms.<\/p>\n
SELECT A,D FROM TestingWideIndexes WHERE A=180 and B=3
\n— Table ‘TestingWideIndexes’. Scan count 1, logical reads 268
\n–SQL Server Execution Times:
\n—\u00a0\u00a0 CPU time = 16 ms,\u00a0 elapsed time = 0 ms.<\/p>\n
DROP INDEX Testing_1 ON TestingWideIndexes
\nCREATE INDEX Testing_2 ON TestingWideIndexes (A, B) INCLUDE (D)<\/p>\n
SELECT A,B FROM TestingWideIndexes WHERE A=180 and B=3
\n— Table ‘TestingWideIndexes’. Scan count 1, logical reads 3
\n— SQL Server Execution Times:
\n—\u00a0\u00a0 CPU time = 0 ms,\u00a0 elapsed time = 0 ms.<\/p>\n
SELECT A,D FROM TestingWideIndexes WHERE A=180 and B=3
\n— Table ‘TestingWideIndexes’. Scan count 1, logical reads 3
\n— SQL Server Execution Times:
\n—\u00a0\u00a0 CPU time = 0 ms,\u00a0 elapsed time = 0 ms.<\/p>\n
So to answer the question, the wider index hasn’t slowed the query down, it’s made it faster.<\/p>\n
All well and good. What about scans though? With more index leaf pages, they’ll require more IOs and should be slower.<\/p>\n
— with both indexes created
\nselect A, B from TestingWideIndexes WITH (Index = Testing_1)
\nselect A, B from TestingWideIndexes WITH (Index = Testing_2)<\/p>\n
Results:<\/p>\n
Table ‘TestingWideIndexes’. Scan count 1, logical reads 188
\nSQL Server Execution Times:
\nCPU time = 32 ms,\u00a0 elapsed time = 15141 ms.<\/p>\n
Table ‘TestingWideIndexes’. Scan count 1, logical reads 813
\nSQL Server Execution Times:
\nCPU time = 31 ms,\u00a0 elapsed time = 15660 ms.<\/p>\n
I ran it several times and the CPU times varied on each run, sometimes the wide index had a higher CPU time, sometimes the narrow one did. They were always very close. So again here, the wider index has not slowed the query down.<\/p>\n","protected":false},"excerpt":{"rendered":"