Home/ Questions/Q 6090757
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T12:15:02+00:00

Let’s say I have a table like this: CREATE TABLE t( [guid] [uniqueidentifier] NOT

  • 0

Let’s say I have a table like this:

CREATE TABLE t(
  [guid] [uniqueidentifier] NOT NULL,
  [category] [nvarchar](400)
  {,...other columns}
  )

Where guid is my primary key, and has a clustered index.

Now, I want an index that covers both category and guid, because I’m rolling up some other stuff related to t by category, and I want to avoid including the t table itself.

Is it sufficient to create index covering category, or do I need to include guid as well?

I would expect SQL Server indexes to point directly to page offsets in t rather than simply referring to a guid primary key value, which means I would need to explicitly include the PK column to avoid hitting t. Is this the case?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Actually your assumption is wrong – all SQL Server non-clustered indices do include the clustering key (single or multiple columns) and do not point directly at some physical page.

    This prevents SQL Server from having to reorganize and update lots of index entries when a page needs to be split in two or relocated. So if you are seeking in a non-clustered index and you find a value, then you have the clustering key and SQL Server will need to do a “bookmark lookup” (or key lookup) to retrieve the actual data page (the leaf page in the clustering index) to get the whole set of data belonging to a single row.

    That said – if you ever have a situation where it depends on the ordering of the key columns, then you still might need to create an index specifically on (guid, category) – of course, in that case, SQL Server is smart enough to figure out that the clustering key column is already in the index and won’t be adding it one more time.

    The fact that the clustering key column(s) are inlcuded in every single non-clustered index is another strong reason why your clustering keys should be narrow, static and unique. Making them too wide (anything beyond 8 byte) is a sure recipe for bloat and slow-down.

    • 0