Hi Jeff,

The 8KB event was already on my schedule. I look forward to your session … this article is 7 years old so I look forward to updating it after the event.

Randy

You, good Sir, are invited to a presentation on GUIDs on the 28th of July, 2021. It will change your mind about most of what you’ve stated above. In the end, I demonstrate that I can add 100,000 rows per day into a Random GUID Clustered Index for 58 straight days (that’s 5.8 MILLION rows) with almost no page splits, less than 1% fragmentation, and no index maintenance during the entire period. Here’s the link to the event…

https://eightkb.online/

To summarize, I destroy the myth of GUID fragmentation and I lay waste to the current “Best Practices” for index maintenance that most of the world follows. I also demonstrate how ever-increasing indexes and the use of NEWSEQUENTIALID() can make things really bad and how we can actually use Random GUIDs to PREVENT fragmentation.

I don’t know you personally but I believe you’re going to really enjoy this one. Heh… water cooled helmets are optional but strongly recommended. 😀

Stay tuned for a followup article that will cover both of these items. The other big issue I’ll cover is storage. GUID’s are much larger than the corresponding integer datatypes.

The problem with that is that you’re just moving the problem. In a heap, you’ll need a nonclustered index on the primary key. The nonclustered index will suffer from the same problems as the clustered index described above. And unless you add a bunch of columns to it, you’ll also be incurring a key lookup every time you use it.

This brings up a good point though. I have had customers who tried to fix this problem by adding an identity field to the table and clustered on that, turning the primary key into a nonclustered unique index. Just like above, that just moves the problem into another index and introduces some new ones as well.

Generally speaking, heaps are usually a bad idea in SQL Server.