Is a GUID unique 100% of the time?

Question

Is a GUID unique 100% of the time?

Will it stay unique over multiple threads?

Answer 1

While each generated GUID is not guaranteed to be unique, the total number of unique keys (2^128 or 3.4×10^38) is so large that the probability of the same number being generated twice is very small. For example, consider the observable universe, which contains about 5×10^22 stars; every star could then have 6.8×10^15 universally unique GUIDs.

From Wikipedia.

Answer 2

Yes, a GUID should always be unique. It is based on both hardware and time, plus a few extra bits to make sure it's unique. I'm sure it's theoretically possible to end up with two identical ones, but extremely unlikely in a real-world scenario.

Here's a great article by Raymond Chen on Guids:

http://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx

Answer 3

The simple answer is yes.

Raymond Chen wrote a great article on GUIDs and why substrings of GUIDs are not guaranteed unique. The article goes in to some depth as to the way GUIDs are generated and the data they use to ensure uniqueness, which should go to some length in explaining why they are :-)

Answer 4

MSDN:

There is a very low probability that the value of the new Guid is all zeroes or equal to any other Guid.

Answer 5

Is a GUID unique 100% of the time?

Not guaranteed, since there are several ways of generating one. However, you can try to calculate the chance of creating two GUIDs that are identical and you get the idea: a GUID has 128 bits, hence, there are 2¹²⁸ distinct GUIDs – much more than there are stars in the known universe. Read the wikipedia article for more details.

Answer 6

Guids are statistically unique. The odds of two different clients generating the same Guid are infinitesimally small (assuming no bugs in the Guid generating code). You may as well worry about your processor glitching due to a cosmic ray and deciding that 2+2=5 today.

Multiple threads allocating new guids will get unique values, but you should get that the function you are calling is thread safe. Which environment is this in?

Answer 7

Theoretically, no, they are not unique. It's possible to generate an identical guid over and over. However, the chances of it happening are so low that you can assume they are unique.

I've read before that the chances are so low that you really should stress about something else--like your server spontaneously combusting or other bugs in your code. That is, assume it's unique and don't build in any code to "catch" duplicates--spend your time on something more likely to happen (i.e. anything else).

I made an attempt to describe the usefulness of GUIDs to my blog audience (non-technical family memebers). From there (via Wikipedia), the odds of generating a duplicate GUID:

• 1 in 2^128
• 1 in 340 undecillion (don’t worry, undecillion is not on the quiz)
• 1 in 3.4 × 10^38
• 1 in 340,000,000,000,000,000,000,000,000,000,000,000,000

Answer 8

If your system clock is set properly and hasn't wrapped around, and if your NIC has its own MAC (i.e. you haven't set a custom MAC) and your NIC vendor has not been recycling MACs (which they are not supposed to do but which has been known to occur), and if your system's GUID generation function is properly implemented, then your system will never generate duplicate GUIDs.

If everyone on earth who is generating GUIDs follows those rules then your GUIDs will be globally unique.

In practice, the number of people who break the rules is low, and their GUIDs are unlikely to "escape". Conflicts are statistically improbable.

Answer 9

As a side note, I was playing around with Volume GUIDs in Windows XP. This is a very obscure partition layout with three disks and fourteen volumes.

\\?\Volume{23005604-eb1b-11de-85ba-806d6172696f}\ (F:)
\\?\Volume{23005605-eb1b-11de-85ba-806d6172696f}\ (G:)
\\?\Volume{23005606-eb1b-11de-85ba-806d6172696f}\ (H:)
\\?\Volume{23005607-eb1b-11de-85ba-806d6172696f}\ (J:)
\\?\Volume{23005608-eb1b-11de-85ba-806d6172696f}\ (D:)
\\?\Volume{23005609-eb1b-11de-85ba-806d6172696f}\ (P:)
\\?\Volume{2300560b-eb1b-11de-85ba-806d6172696f}\ (K:)
\\?\Volume{2300560c-eb1b-11de-85ba-806d6172696f}\ (L:)
\\?\Volume{2300560d-eb1b-11de-85ba-806d6172696f}\ (M:)
\\?\Volume{2300560e-eb1b-11de-85ba-806d6172696f}\ (N:)
\\?\Volume{2300560f-eb1b-11de-85ba-806d6172696f}\ (O:)
\\?\Volume{23005610-eb1b-11de-85ba-806d6172696f}\ (E:)
\\?\Volume{23005611-eb1b-11de-85ba-806d6172696f}\ (R:)
                                     | | | | |
                                     | | | | +-- o
                                     | | | +---- i
                                     | | +------ r
                                     | +-------- a
                                     +---------- m

It's not that the GUIDs are very similar but the fact that all GUIDs have the string "mario" in them. Is that a coincidence or is there an explanation behind this?

Now, when googling for part 4 in the GUID I found approx 125.000 hits with volume GUIDs.

Conclusion: When it comes to Volume GUIDs they aren't as unique as other GUIDs.

Answer 10

It should not happen. However, when .NET is under a heavy load, it is possible to get duplicate guids. I have two different web servers using two different sql servers. I went to merge the data and found I had 15 million guids and 7 duplicates.

Answer 11

Yes! I will give you my personal guarantee that all properly implemented GUID generators will never generate non-unique IDs.

There you go, a guarantee, it can be backed by some of my karma, or something...

Answer 12

Specifically SQL Server auto-created guids (default value (newid())) are not unique when it is under a heavy load (I do not know if this also applies to .NET; I would think the guid generation engine in SQL Server would be based on .NET). In my 15 million row database (across two servers and two databases), I had 7 duplicate guids. Now, those are the only duplicates I know of; there is a unique constraint on my guid column on each database, so it is possible there were more attempted duplicates but were not added because of the constraints.