碰撞的风险略有提高,但仍然很小.考虑一下： @H_403_2@> Comb和NEWID / NEWSEQUENTIALID都包含精度低至几ms†的时间戳.因此,除非您在所有这些不同来源的完全相同的时刻生成大量的ID,否则ID几乎不可能发生冲突.
> GUID的不是基于时间戳的部分可以被认为是随机的;大多数GUID算法将这些数字放在PRNG上.因此,这些其他10个字节之间的冲突的可能性与使用两个单独的随机数生成器并观察冲突的顺序相同.

@H_403_2@考虑一下 – PRNG可以并且重复数字,所以它们之间的碰撞的可能性并不比仅使用其中一个的碰撞高得多,即使它们使用稍微不同的算法.这有点像每周玩相同的彩票号码,而每周选择一个随机的组合 – 获胜的几率是完全一样的.

@H_403_2@现在,请记住,当您使用像Guid.Comb这样的算法时,您只能拥有10位的唯一性,相当于1024个独立的值.因此,如果您在几毫秒内生成大量的GUID,您将获得冲突.但是,如果您以相当低的频率生成GUID,则同时使用多少种不同的算法并不重要,因此碰撞的可能性实际上仍然不存在.

@H_403_2@你绝对肯定的最好方法是进行测试;所有2或3(或许多您使用)生成GUID,同时定期,并将它们写入日志文件,并查看是否遇到冲突(如果是,有多少).这应该给你一个好主意,这是多么安全这是在实践中.

@H_403_2@附：如果您使用NHibernate的梳状生成器为集群主键生成GUID,请考虑使用NEWSEQUENTIALID()而不是NEWID() – Comb的整个点是避免页面拆分,如果您有其他的使用非顺序算法的过程.您还应使用Guid.NewGuid更改任何代码以使用相同的Comb生成器 – NHibernate中使用的实际Comb算法为not complicated,并且可以在您自己的域逻辑中轻松复制.

@H_403_2@†请注意,对NEWID似乎有一些争议,以及它是否包含时间戳.在任何情况下,由于它是基于MAC地址,所以可能值的范围远远小于V4 GUID或Comb.进一步的原因,我建议坚持数据库外的Comb GUID和数据库内的NEWSEQUENTIALID.