Home/ Questions/Q 1001605
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T07:42:03+00:00

I’m trying to understand how sequential guid performs better than a regular guid. Is

  • 0

I’m trying to understand how sequential guid performs better than a regular guid.

Is it because with regular guid, the index use the last byte of the guid to sort? Since it’s random it will cause alot of fragmentation and page splits since it will often move data to another page to insert new data?

Sequential guid sine it is sequential it will cause alot less page splits and fragmentation?

Is my understanding correct?

If anyone can shed more lights on the subject, I’ll appreciated very much.

Thank you

EDIT:

Sequential guid = NEWSEQUENTIALID(),

Regular guid = NEWID()

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You’ve pretty much said it all in your question.

    With a sequential GUID / primary key new rows will be added together at the end of the table, which makes things nice an easy for SQL server. In comparison a random primary key means that new records could be inserted anywhere in the table – the chance of the last page for the table being in the cache is fairly likely (if that’s where all of the reads are going), however the chance of a random page in the middle of the table being in the cache is fairly low, meaning additional IO is required.

    On top of that, when inserting rows into the middle of the table there is the chance that there isn’t enough room to insert the extra row. If this is the case then SQL server needs to perform additional expensive IO operations in order to create room for the record – the only way to avoid this is to have gaps scattered amongst the data to allow for extra records to be inserted (known as a Fill factor), which in itself causes performance issues because the data is spread over more pages and so more IO is required to access the entire table.

    • 0