所以我完全理解创建两个 GUID 的数学可能性具有相同数字的值。但假设它们是独一无二的是可以接受的做法吗？
例如，我正在使用一个处理医疗文件的系统。当我开始布局数据库结构时，经理(不是很懂技术，但喜欢认为他是，并且委托(delegate)一些事情最好留给更有技术头脑的人来决定)说他想使用 GUID 来分隔不同的医疗记录INT，因为它“更独特”。我解释了 INT 如何始终是唯一的，因为它是连续的。我建议我们使用 BigINT，如果它能让他感觉更舒服，因为里面有更多的数字，那么如果地球上的人口增加到人们只适合在地球上挨着站着的程度，但他坚持使用GUID。
我的感觉是，虽然混淆几乎是不可能的，但在处理病历时，为什么要冒这个险呢？在这种情况下使用 GUID 与 INT 相比有什么优势？
最佳答案
But is it acceptable practice to assume it is unique?
是的。这就是UUID的全部目的。 , 在没有集中协调的情况下用作可靠的唯一标识符。 (GUID 是 Microsoft 的 UUID 变体。)
只有您(或您的适当管理人员)才能对您的特定项目做出最终判断。
但是，如果您真正开始意识到 12x 位的数字范围的巨大(这实际上是人类思维无法理解的)，那么您就会知道可以从您的担忧列表中删除正确生成的 UUID 的使用。
我所说的“正确生成”是指使用日期时间版本，或者如果有加密强随机数生成器支持，则对于较少数量的值使用随机数(版本 4)。今天几乎每个现代操作系统都包含一个 UUID 生成库。或者您可以使用 OSSP UUID项目。 不正确生成的将包括您自己的实现，您可能会看到关于互联网的恶意攻击。
至于使用数据库的自动递增序列号的建议，我认识的每个具有多年实际经验的数据库人员都被这些建议所困扰。我从未听说过或读过任何人与正确生成的 UUID 发生冲突。我并不是说序列一定是坏的或没有它们的位置，我只是说当我听到人们因为 UUID 的一些超天文难以理解的微小可能性而远离 UUID 时，我所能做的就是笑碰撞并选择一个序列。
when dealing with medical records, why take the chance?
由于错误的数据输入或处理记录的其他人为错误，您的医疗系统更有可能出现故障。但是，您是否派 3 名值类职员独立三次输入相同的数据以减少出错的可能性？不。而且这种风险在数学上比 UUID 问题更有可能发生。然而，我所知道的每家医疗机构都没有考虑就接受了这种巨大的风险。
What is the advantage of using a GUID vs an INT
优点包括:
- 无需管理您的序列。
示例包括:重置开发、测试和生产环境。或者在恢复备份时。或者在系统的串口生成库出错后修复序列(我自己的经验)。 - 避免用户的直觉假设混淆序列中缺失的数字。
我经常有这样的谈话。 - Federating data分布式系统之间。
这是最大的优势，每个系统都可以独立行动，但可以轻松地与其他系统来回共享数据。如果没有 UUID，管理开销和出错风险一开始会很麻烦，而且只会随着时间的推移而增加。
缺点包括:
- 更大的内存和存储使用。
序列号通常是 32 位整数，有时是 64 位。 good database native 支持 UUID 作为数据类型将使用 128 位。 - 人类可读性较差。
一个解决方法是在临时工作中只读取几个第一个或最后一个数字。 - 索引效率可能较低，条目数量非常多。
关于mysql - 我知道 GUID 几乎是唯一的。但是假设它是独一无二的是可以接受的做法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32513357/