views:

164

answers:

1

I know that using GUID generated by newid isn't a good candidate for primary key for performance issues.

How about a composite primary key with {newsequentialid(), newid()} so a new GUID is guranteed to be greater than the one generated previously?

Is there a performance issue here too?

You may think why would anyone do this but i am writing a code analysis rule and don't know what crazy things that users will do :)

Thanks

+3  A: 

This is even worse than a straight, single GUID created by using just newid().

Why??

  • it's still totally random (because of the newid() part) thus causing massive index fragmentation
  • it's twice as large as a single GUID, making all your non-clustered indices more bloated and less efficient (32 bytes vs. 4 bytes for an INT IDENTITY)

So I would recommend to either:

  • stick with just a newsequentialid() as the default for your PK, if you really want and need a GUID-style PK
  • use a INT/BIGINT IDENTITY for optimal performance (if replication is not a requirement)

That's the best two choices you have. See Kimberly Tripp's excellent articles on why a random GUID is a really really bad choice for a clustering key:

marc_s
... and newsequentialid will not continue the sequence after a SQL instance restart...
gbn