有信息就在网上和StackOverflow的GUID的一个很好的协议。 事实上，关于独特的无穷无尽的问题。 这不是一个问题，大约2 ^ 128的独特性 。
我的问题是，以确定第一部分 ，secifically 前四个字节的GUID是多么随意在.NET。 根据研究，这是所谓的时间戳的至少显著32位。 但是，如何转换的时间戳？ 这究竟是随机的？
是否有人知道如何第一部分由.NET构建，如果是真正在平均4个字节传播的？
如何使用时间戳来构建前32位 ？
如何时钟精度有影响吗？
是由微软提出的任何企图，以确保前4个字节倾向于随机的或不是？
WHY：高卷GUID使用有2个主要的商业案例在第4个字节好的随机的GUID。 如果你有一个甚至蔓延为每个新的GUID，那么你可以使用基于第1,2,3或4个字节的表分区根据你需要多少个分区。 一天我看到一个2十亿行的表拥有1000万个插入，使用前2个字节为分区键128个分区。 DB2的关键的第一部分下注意必须使用。 报价DB2 DBA。 在DB这极大地提高了吞吐量。 第二个用途是批量作业并行键布局。 如果你知道你大概有N行作为一个批处理任务，您可以分配键范围到并行作业。 如果没有均匀分割，调度员必须首先从和为每个作业键计算。 如果这意味着读100个百万和管理在内存中只是派遣工作时，首先x分钟是输给了工作调度。 在这个例子中我看到它是大约15分钟。 因此，有使用2个绝佳的理由和希望均匀地涂抹的GUID。
在SAP银行系统实际上引入了一个自定义的GUID程序来解决的GUID的第一部分缺乏随机性。 对于那些访问SAP的银行系统，功能BANK_DISTRIBUTED_ID_CREATE。 在代码中的注释解释为什么他们做到了。 那些可以访问SAP支持有一张纸条496904解释了为什么他们认为有必要修复的GUID。
在此之前的自定义例程有在AIX下的GUID明确的时滞。 C ++内核。 独特的是，但随机的，特别是第一部分，显然不是。
更新：当我决定写一个程序来调查：.NET 4在Windows XP，戴尔英特尔Core 2 Duo。
我已经包括测试程序结果柜面如果利率。 使用GUID生成
var G = Guid.NewGuid();
结果一下就OK样品亿点的GUID。（大组仍在运行中）对于我而言，这看起来均匀地涂抹足够承担确定。
Byte 0: with Value 6A was least frequent : 389140 times
Byte 0: with Value 58 was most frequent : 392241 times
Byte 1: with Value 25 was least frequent : 388905 times
Byte 1: with Value B3 was most frequent : 392552 times
Byte 2: with Value D2 was least frequent : 389114 times
Byte 2: with Value CC was most frequent : 391984 times
Byte 3: with Value 66 was least frequent : 388744 times
Byte 3: with Value 16 was most frequent : 392838 times
编辑：研究背景的基础上增加评论
我已经看到了AIX系统上的GUID的样本。 我们有超过20十亿了。 他们不是均匀分布。 有在2个字节的明显时滞。 其结果是一个特殊的程序被引入，产生均匀的GUID。 我在想，如果.NET也有类似的歪斜
