Skip to content

Uniqueidentifier with NewId

MichelleTaylorRG edited this page Jun 19, 2019 · 1 revision

From http://blogs.lessthandot.com/index.php/DataMgmt/DBProgramming/best-practice-don-t-not-cluster-on-uniqu:

There can only be one clustered index per table because SQL Server stores the data in the table in the order of the clustered index . When you use a UniqueIdentifier as the first column in a clustered index, every time you insert a row in the table, it is almost guaranteed to be inserted in to the middle of the table. SQL server stores data in 8K pages. If a page is full, SQL Server will do a page split, which causes another 8k page to be allocated and half the data from the previous page to be moved to the new page. Individually, each page split is fast but does take a little bit of time. In a high transaction environment, there could be many page splits happening frequently, which ultimately result in slower performance.

When you use an Identity column for a clustered index, the next value inserted is guaranteed to be higher than the previous value. This means that new rows will always be added to the end of the table and you will not get unnecessary page splits for table fragmentation.

SQL Server 2005 introduced a new function called NewSequentialId(). This function can only be used as a default for a column of type UniqueIdentifier. The benefit of NewSequentialId is that it always generates a value greater than any other value already in the table. This causes the new row to be inserted at the end of the table and therefore no page splits.

How to correct it: Use NewSequentialId() instead of NewId.

Clone this wiki locally