GUID or Varchar(36)?

Emmanuel Tissera's photo
Emmanuel Tissera
·Aug 27, 2015·

2 min read

GUID or Varchar(36)?

While working on an application which had a foreign key GUID reference, we had to change the implementation for that field to accept a string. Then we came across the question as to whether GUIDs or a Varchar(36) field would perform better?

First off, what is a GUID?

In essence a GUID is an integer value. Of course, it is a 128 bit integer value taking 16 bytes to store. What we usually see (b6aa92e9-5ae9-47f4-ad2f-ebc36452c61d) is the human readable hexadecimal string. But GUID values are not stored or processed as strings. The other difference to a 128-bit integer is how the next GUID is generated – randomly, rather than sequentially.

See comments in this article for more info:
http://blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/

Why compare against Varchar(36)?

That's because the hexadecimal representation of a GUID is 36 characters long. So if you are storing the GUID as a string, you need a Varchar(36) field.

See this article on the pros and cons:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/df3caee5-3751-469b-a943-f0c8cb501f75/unique-identifier-vs-varchar36-for-storing-guids?forum=transactsql

So what performs better?

Having said that a GUID takes 16 bytes and Varchar(36) takes 36 bytes, the GUID will always outperform it's counterpart. Other than that, it would be somewhat faster to compare GUID values because it's a simple numeric comparison and doesn't have to consider lexical rules.

Caveats

If it is either a GUID or Varchar(36) field, make sure that it is indexed to have a performance gain. Also consider your requirements to make sure what suits you best.


This article was originally written on Google's Blogger platform and ported to Hashnode on 17 Sep 2022.

 
Share this