En mi trabajo, usamos UUID como PK. Lo que puedo decirte por experiencia es que NO LOS USE como PK (SQL Server por cierto).
Es una de esas cosas que cuando tienes menos de 1000 registros está bien, pero cuando tienes millones, es lo peor que puedes hacer. ¿Por qué? Debido a que los UUID no son secuenciales, cada vez que se inserta un nuevo registro, MSSQL debe ir a la página correcta para insertar el registro y luego insertar el registro. La consecuencia realmente fea de esto es que las páginas terminan todas en diferentes tamaños y terminan fragmentadas, por lo que ahora tenemos que hacer una desfragmentación periódica.
Cuando usa un incremento automático, MSSQL siempre irá a la última página y terminará con páginas del mismo tamaño (en teoría), por lo que el rendimiento para seleccionar esos registros es mucho mejor (también porque los INSERT no bloquearán la tabla/página para tanto tiempo).
Sin embargo, la gran ventaja de usar UUID como PKs es que si tenemos clusters de DBs, no habrá conflictos al fusionarlos.
Recomendaría el siguiente modelo:1. PK INT Identidad2. Columna adicional generada automáticamente como UUID.
De esta manera, el proceso de fusión es posible (UUID sería su clave REAL, mientras que PK sería solo algo temporal que le brinda un buen rendimiento).
NOTA:que la mejor solución es usar NEWSEQUENTIALID (como decía en los comentarios), pero para aplicaciones heredadas sin mucho tiempo para refactorizar (y peor aún, sin controlar todas las inserciones), no es posible hacerlo. a partir de 2017, diría que la mejor solución aquí es NEWSEQUENTIALID o hacer Guid.Comb con NHibernate.
Espero que esto ayude
