Performance impact of using GUID in SQL Server

Question

I have tried searching this before asking but every result I have found mentions GUIDs as a PK which is not the case here.

I have a database that's using INT as the PK on all tables. However the data is accessed via API calls and a requirement was for the INT value not to be returned or used in any API. Therefore I thought of having an extra column on the tables containing a GUID.

Now my question is, if I Index the GUID column what kind of performance impact will this have? Would it be positive or negative? Bear in mind the GUID is NOT a PK or FK.

Answer 1

I think you are on the right track, but don't take it from me...

In the comments section on one of Kimberly Tripp's articles, she responds to a comment that advocates the opposite of your position, and she disagrees and argues for the same solution you are proposing (nonclustered indexed guid with a clustered int/bigint primary key).

Herman:

If the GUID is the intrinsic identifier for the entity being modelled (ie used by selects) then it should be the clustered primary key without question. The reason is that adding a surrogate identity key (of int or bigint) and demoting the GUID primary key to a column with an index/unique constraint requires 2 indexes to be maintained and slows down, in my experience, by a factor of 2.

---

Kimberly Tripp

Hey there Herman – Actually, I disagree. For point-based queries using a nonclustered index does not add a significant amount of costly IOs. And, the maintenance of a nonclustered index that's heavily fragmented is a lot cheaper than the required maintenance on a heavily fragmented clustered index. Additionally, the GUID might make your nonclustered indexes unnecessarily wide – making them take: more log space, more disk space, more cache as well as adding time on insert and access (especially in larger queries/joins).

So, while you might not feel like an arbitrary/surrogate key is useful (because you never directly query against it) it can be incredibly efficient to use indirectly through your nonclustered indexes. There's definitely an element of “it depends” here but if you have even just a few nonclustered indexes then it's likely to be more beneficial than negative and often significantly so.

Cheers,
kt ~ GUIDs as PRIMARY KEYs and/or the clustering key - Kimberly L. Tripp

Answer 2

This should be fine. Of course, you have the normal impact of any index and any column taking up more space. So, data modifications will be a bit slower. The use of a GUID to locate a record versus an integer is slightly slower. Unless you have a very high throughput application, these are probably not important considerations.

One key point is that the GUID column should not be clustered. This is very important because GUIDs are random, but primary keys are ordered. If a GUID were used for a clustered index, almost every insert would go between two existing records, requiring a lot of movement of data. By contrast, an identity column as a clustered index always inserts at the end of the data.

I am guessing that your references on GUIDs have discussed this issue.