Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I have recently read a article about how nonclustered indexes are matching table rows. I will try to summarize what I believe is relevant to your question.</p> <p>There are two types of tables (in the context of indexes):</p> <ul> <li>heap - a table without clustered index</li> <li>clustered index - a table with clustered index</li> </ul> <p><strong>In the first case</strong> a nonclustered index is matching rows using RIP-Based bookmarks which has the following format:</p> <pre><code>file number - page number - row number </code></pre> <p>and a nonclustered index is looking like this:</p> <p><img src="https://i.stack.imgur.com/3aCsG.png" alt="enter image description here"></p> <p>You can see the RIP bookmark is in red.</p> <blockquote> <p>Generally speaking, the rows of a heap do not move; once they have been inserted into a page they remain on that page. To be more technically-precise: rows in a heap seldom move, and when they do move, they leave a forwarding address at the old location. The rows of a clustered index, however, can move; that is, they can be relocated to another page during data modification or index reorganization.</p> </blockquote> <p><strong>In the second</strong> the nonclustered index is using the index key of the clustered index as a bookmark and the clustered index itself should meet several criteria:</p> <ol> <li>it must be unique</li> <li>it should be short</li> <li>it should be static</li> </ol> <p>I am going to describe the first criteria (the others are described in the link below):</p> <blockquote> <p>Each index entry bookmark must allow SQL Server to find the one row in the table that corresponds to that entry. If you create a clustered index that is not unique, SQL Server will make the clustered index unique by generating an additional value that "breaks the tie" for duplicate keys. This extra value is generated by SQL Server to create uniqueness is called the uniquifier and is transparent to any client application. You should carefully consider whether or not to allow duplicates in a clustered index, for the following reasons:</p> <ol> <li><p>Generating uniquifiers is extra overhead. SQL Server must decide, at insert time, if a new row's key is a duplicate of an existing row's key; and, if so, generate a uniquifier values to add to the new row</p></li> <li><p>The uniquifier is a meaningless piece of information; a meaningless piece of information that is being propagated into the table's nonclustered indexes. It's usually better to propagate a meaningful piece of information into the nonclustered indexes.</p></li> </ol> </blockquote> <p>The whole article can be found <a href="http://www.sqlservercentral.com/articles/Stairway+Series/72281/" rel="nofollow noreferrer">here</a>.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload