GUIDs or unique identifiers have the benefit of being globally unique across machines and databases. This gives us a tremendous benefit in that we know that we’re always going to have a unique value. It’s composed partially of a seed that starts with the MAC address of the computer it’s on, and then the time stamp where it was generated. So between those two things, they’re able to ensure global uniqueness across systems. It is extremely, extremely rare that there are what are known as GUID collisions, where GUIDs have the same value in multiple systems.
Problems of using GUID
There’s two main problems with GUIDs. They have a size and selectivity problem.
GUID take up more pages. If you make your rows a lot wider, for example, using a GUID as your primary key, you’re going to have a lot more what are known as page splits, that’s where pages split across rows, and increased fragmentation.
GUIDs are inefficient at join operations, ’cause they’re very large values in terms of how big they are.
If you’re generating them from your application code, your GUIDs are going to be completely random.
When you have to merge that data from multiple systems, you’re going to need a guarantee of uniqueness.
When you don’t what to auto increment numbers like a primary int type.