Home/ Questions/Q 6689029
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T05:28:18+00:00

I’ve a table which is defined like this CREATE TABLE [dbo].[MyTable]( [MyTableId] [bigint] IDENTITY(1,1)

  • 0

I’ve a table which is defined like this

CREATE TABLE [dbo].[MyTable](
    [MyTableId] [bigint] IDENTITY(1,1) NOT NULL,
    [SomeTable2Id] [bigint] NOT NULL,
    [SomeTable3Id] [bigint] NOT NULL,
    [SomeData] [smallint] NOT NULL,
 CONSTRAINT [PK_MyTable] PRIMARY KEY NONCLUSTERED 
(
    [MyTableId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]

Apart from above PK_MyTable NONCLUSTERED index, I’ve few other NONCLUSTERED indexes over SomeTable2Id and SomeTable3Id

I think creating CLUSTERED index above makes more sense but I’m wondering is there any good justification for NOT creating a CLUSTERED index and instead creating NONCLUSTERED?

PS There are lot of questions asked over these topics but couldn’t find relevant one (in top 20 list). If this has been asked, please redirect me to the related question post.

EDIT: Consider a case where MyTable is mapping two other tables SomeTable2 and SomeTable3 and instead of having composite key, we have this MyTableId So most of the time my queries have either SomeTable2Id or SomeTable3Id and request to get other id. So in this light of usage of this table, do we really need to bother with creation of a clustered index over MyTableId or two nonclustered indices over SomeTable2Id and SomeTable3Id are sufficient?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think you definitely should have MyTableId as your the key in a clustered index without further information about how the table is actually used.

    Remember, you are choosing between the table being a clustered index or a heap. A clustered index is not an index on the table, but identifies that the table is stored in a B-tree based on the clustered index key.

    On both kinds of tables, non-clustered indexes can also be used.

    For read performance (particularly on wider tables), the non-clustered indexes (potentially with included columns) are going to be where you are looking for gains.

    • 0