<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.sqlserver.org.au/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Debunking myths about clustered indexes - part 1 (CIXs worsen bookmark lookups)</title><link>http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/10/363.aspx</link><description>One of the most widely published indexing "best practises" is that you should create a clustered index (CIX) on every table in your database. For many years, I accepted this as one of the "golden indexing rules" but over the past few years&amp;nbsp;I have</description><dc:language>en-AU</dc:language><generator>CommunityServer 2.0 (Build: 60217.2664)</generator><item><title>re: Debunking myths about clustered indexes - part 1 (CIXs worsen bookmark lookups)</title><link>http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/10/363.aspx#424</link><pubDate>Fri, 03 Nov 2006 22:20:28 GMT</pubDate><guid isPermaLink="false">6d5687b6-8fdc-4d13-899b-485dc578ece0:424</guid><dc:creator>Hugo Kornelis</dc:creator><description>Hi Greg,&lt;br&gt;&lt;br&gt;You are right that a bookmark lookup through a clustered index requires the traversal of the B-tree for that index. This usually means three page reads for big table and four for HUGE tables.&lt;br&gt;&lt;br&gt;However, you are NOT right that a bookmark lookup on a heap only takes a single read. That is only true for a completely &amp;quot;fresh&amp;quot; heap, or for a heap where existing rows are never updated. Update activity often causes rows to be moved to a new location. In such a case, a forwarding pointer is left at the original location. On a bookmark lookup, the nonclustered index will point to the original location, where the forwarding pointer will then provide the current location of the row. That means that for a heap, the average number of page reads for a single bookmark lookup will gradually increase from a theoretic minimum of 1 up to a theoretic maximum of 2.&lt;br&gt;&lt;br&gt;Now before you say that 2 page reads is still less than the 3 to 4 page reads for a bookmark lookup in a clustered index, consider WHICH pages are read. For a heap, each qualifying row from the nonclustered index will point to a page randomly somewhere in the file, and a forwarding pointer will point to yet another random location. Once the table size is sufficiently larger than the available data cache, each logical read will also be a physical read. For a clustered index, 1 of the reads is the data page, the other 2 or 3 are for root and intermediate pages of the B-tree. These pages are accessed all the time, so they'll never be pushed out of the cache; only the data page will require a physical read.&lt;br&gt;&lt;br&gt;Bottom line: for large tables with some update activity, each bookmark lookup will cost 1 physical read and 2 or 3 reads from cache if the table has a clustered index, or somewhere between 1 and 2 physical reads if it's a heap. Considering the relatively huge performance hit of physical reads, it doesn't take an awful lot of updates before the scale starts to swing back towards the clustered index.&lt;br&gt;&lt;br&gt;Best, Hugo</description></item><item><title>Debunking myths about clustered indexes - part 5 - a real world example</title><link>http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/10/363.aspx#696</link><pubDate>Thu, 07 Jun 2007 14:52:03 GMT</pubDate><guid isPermaLink="false">6d5687b6-8fdc-4d13-899b-485dc578ece0:696</guid><dc:creator>Anonymous</dc:creator><description>&lt;br&gt;This post discusses a problem experienced last year on one of the highest profile&amp;amp;amp;nbsp;websites in...</description></item><item><title>SQL Server Myths</title><link>http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/10/363.aspx#758</link><pubDate>Wed, 27 Jun 2007 15:26:04 GMT</pubDate><guid isPermaLink="false">6d5687b6-8fdc-4d13-899b-485dc578ece0:758</guid><dc:creator>Anonymous</dc:creator><description>The whole area of &amp;amp;quot;SQL Server myths&amp;amp;quot; is an interesting one. One of the fascinations of working with SQL...</description></item><item><title>How earn $ 1000 a week?</title><link>http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/10/363.aspx#1591</link><pubDate>Sun, 07 Mar 2010 16:04:32 GMT</pubDate><guid isPermaLink="false">6d5687b6-8fdc-4d13-899b-485dc578ece0:1591</guid><dc:creator>AleVaserman</dc:creator><description>You can make from 3000$-5000$ a Month with this program! $30 for each refferal!&lt;br&gt;You will earn money from multiple streams: people search engine, ClickBank, HD Publishing, Google AdSense, HostGator, My Life and GDI (Global Domain International). &lt;br&gt;Visit site: [url=&lt;a rel="nofollow" target="_new" href="http://bit.ly/aLNyID"&gt;http://bit.ly/aLNyID&lt;/a&gt;]acme-people-search.com[/url]</description></item></channel></rss>