Home/ Questions/Q 775851
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T19:21:29+00:00

I have a table storing millions of rows. It looks something like this: Table_Docs

  • 0

I have a table storing millions of rows. It looks something like this:

Table_Docs
ID, Bigint (Identity col)
OutputFileID, int
Sequence, int
…(many other fields)

We find ourselves in a situation where the developer who designed it made the OutputFileID the clustered index. It is not unique. There can be thousands of records with this ID. It has no benefit to any processes using this table, so we plan to remove it.

The question, is what to change it to… I have two candidates, the ID identity column is a natural choice. However, we have a process which does a lot of update commands on this table, and it uses the Sequence to do so. The Sequence is non-unique. Most records only contain one, but about 20% can have two or more records with the same Sequence.

The INSERT app is a VB6 piece of crud throwing thousands insert commands at the table. The Inserted values are never in any particular order. So the Sequence of one insert may be 12345, and the next could be 12245. I know that this could cause SQL to move a lot of data to keep the clustered index in order. However, the Sequence of the inserts are generally close to being in order. All inserts would take place at the end of the clustered table. Eg: I have 5 million records with Sequence spanning 1 to 5 million. The INSERT app will be inserting sequence’s at the end of that range at any given time. Reordering of the data should be minimal (tens of thousands of records at most).

Now, the UPDATE app is our .NET star. It does all UPDATES on the Sequence column. “Update Table_Docs Set Feild1=This, Field2=That…WHERE Sequence =12345” – hundreds of thousands of these a day. The UPDATES are completely and totally, random, touching all points of the table.

All other processes are simply doing SELECT’s on this (Web pages). Regular indexes cover those.

So my question is, what’s better….a unique clustered index on the ID column, benefiting the INSERT app, or a non-unique clustered index on the Sequence, benefiting the UPDATE app?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First off, I would definitely recommend to have a clustered index!

    Secondly, your clustered index should be:

    • narrow
    • static (never or hardly ever change)
    • unique
    • ever-increasing

    so an INT IDENTITY is a very well thought out choice.

    When your clustering key is not unique, SQL Server will add a 4-byte uniqueifier to those column values – thus making your clustering key and with it all non-clustered indices on that table larger and less optimal.

    So in your case, I would pick the ID – it’s narrow, static, unique and ever-increasing – can’t be more optimal than that! Since the Sequence is used heavily in UPDATE statements, definitely put a non-clustered index on it, too!

    See Kimberly Tripp’s excellent blog posts on choosing the right clustering key for great background info on the topic.

    • 0