Using GUIDs in Primary Keys / Clusted Indexes

Question

I'm fairly well versed in SQL server performace but I constanly have to argue down the idea that GUIDs should be used as the default type for Clusterd Primary Keys.

Assuming that the table has a fairly low amount of inserts per day (5000 +/- rows / day), what kind of performace issues could we run into? How will page splits affect our seek performance? How often should I reindex (or should I defrag)? What should I set the fill factors to (100, 90, 80, ect)?

What if I were inserting 1,000,000 rows per day?

I apologize beforhand for all of the questions, but i'm looking to get some backup for not using GUIDs as our default for PKs. I am however completely open to having my mind changed by the overwehlming knowledge from the StackOverflow user base.

Answer 1

If you are doing any kind of volume, GUIDs are extremely bad as a PK bad unless you use sequential GUIDs, for the exact reasons you describe. Page fragmentation is severe:

                 Average                    Average
                 Fragmentation  Fragment    Fragment   Page     Average 
Type             in Percent     Count       Size       Count    Space Used

id               4.35           7           16.43      115      99.89
newidguid        98.77          162         1          162      70.90 
newsequentualid  4.35           7           16.43      115      99.89

And as this comparison between GUIDs and integers shows:

Test1 caused a tremendous amount of page splits, and had a scan density around 12% when I ran a DBCC SHOWCONTIG after the inserts had completed. The Test2 table had a scan density around 98%

If your volume is very low, however, it just doesn't matter that much.

If you do really need a globally unique ID but have high volume (and can't use sequential IDs), just put the GUIDs in an indexed column.

Answer 2

Drawbacks of using GUID as primary key:

• No meaningful ordering, means indexing doesn't give performance boost as it does with an integer.
• Size of a GUID 16 bytes, versus 2, 4 or 8 bytes for an integer.
• Very difficult for humans to remember, so no good as a reference id.

Advantages:

• Allow non-guessable primary keys that can therefore be less dangerous when displayed in a web page query string or in the application.
• Useful in Databases that don't provide an auto increment or identity data type.
• Useful when you need to join data between two disparate data sources across platforms or environments.

I thought the decision as to whether to use GUIDs was pretty simple, but maybe I'm unaware of other issues.

Answer 3

With such a low inserts per day, I doubt that page splitting should be a significant factor. The real question is how does 5,000 compares with the existing row count, as this would be the main information needed to decide on an appropriate initial fill factor to deffer splits.

This said, I'm personally not a big fan of GUIDs. I understand that they can serve well in some contexts but in many cases they are just "in the way" [of efficiency, of ease of use, of ...]

I find the following questions useful to narrow down on deciding whether GUID should be used or not.

• Will the PK be shared/published ? (i.e. will it be used beyond its internal use within SQL, will applications need these keys in a somewhat persistent fashion? Will users somehow see these keys?
• Could the PK be used to help merge disparate data sources ?
• Does the table have a primary -possibly composite- made from column(s) in the data ? What is the size of this possible this key
• How do the primary keys sort? If composite, are the first few columns selective ?