We have a database in which all the PKs are GUIDs, and most of the PKs are also the clustered index for the table. We know that this is bad (due to the random nature of GUIDs). So, it seems there are basically two options here (short of throwing out GUIDs as PKs altogether, which we cannot do (at least not at this time)).
- We could change the GUID generation algorithm to e.g. the one that NHibernate uses, as detailed in this post, or
- we could, for the tables that are under the heaviest use, change to a different clustered index, e.g. an IDENTITY column, and keep the “random” GUIDs as PKs.
Is it possible to give any general recommendations in such a scenario?
The application in question has 500+ tables, the largest one presently at about 1,5 million rows, a few tables around 500 000 rows, and the rest significantly lower (most of them well below 10K).
Furthermore, the application is installed at several customer sites already, so we have to take any possible negative effects for existing customer into consideration.
Thanks!
If you are able to change your guid generation to a sequential guid generation easily then that is probably your quick win option. The sequential guid will stop the fragmentation on the table whilst remaining as your clustered index. The major downside with a sequential guid though is that they then become guessable which is often not desired and the reason guids are used in the first place.
If you go down the Identity route for your clustered primary key and then just an index on your guid column then you will still get a lot of fragmentation on your guid index. However the fact that the table will no longer get fragmented will be a massive gain.
Finally though, I know you said you can’t do this for now, but, if you don’t NEED to use guids as an index at all then you remove all of these problems.