针对多类型数据库，集群数据库的有序GUID
一、背景
常见的一种数据库设计是使用连续的整数为做主键，当新的数据插入到数据库时，由数据库自动生成。但这种设计不一定适合所有场景。
随着越来越多的使用Nhibernate、EntityFramework等ORM（对象关系映射）框架，应用程序被设计成为工作单元（Unit Of Work）模式，需要在数据持久化之前生成主键，为了保证在多线程并发以及站点集群环境中主键的唯一性，最简单最常见的方式是将主键设计成为GUID类型。
（工作单元：是数据库应用程序经常使用的一种设计模式，简单一点来说，就是对多个数据库操作进行打包，记录对象上的所有变化，并在最后提交时一次性将所有变化通过系统事务写入数据库。目的是为了减少数据库调用次数以及避免数据库长事务。）
GUID（全球唯一标识符）也称为UUID，是一种由算法生成的二进制长度为128位的数字标识符。在理想情况下，任何计算机和计算机集群都不会生成两个相同的GUID。GUID 的总数达到了2^128（3.4×10^38）个，所以随机生成两个相同GUID的可能性非常小，但并不为0。GUID一词有时也专指微软对UUID标准的实现。
（RFC 41222描述了创建标准GUID，如今大多数GUID生成算法通常是一个很长的随机数，再结合一些像网络MAC地址这种随机的本地组件信息。）
GUID的优点允许开发人员随时创建新值，而无需从数据库服务器检查值的唯一性，这似乎是一个完美的解决方案。
很多数据库在创建主键时，为了充分发挥数据库的性能，会自动在该列上创建聚集索引。
我们先来说一说什么是聚集索引。集索引确定表中数据的物理顺序。聚集索引类似于电话簿，按姓氏排列数据。由于聚集索引规定数据在表中的物理存储顺序，因此一个表也只能包含一个聚集索引。它能够快速查找到数据，但是如果插入数据库的主键不在列表的末尾，向表中添加新行时就非常缓慢。例如，看下面这个例子，在表中已经存在三行数据：
此时非常简单：数据行按对应ID列的顺序储存。如果我们新添加一行ID为8的数据，不会产生任何问题，新行会追加的末尾。
但如果我们想插入一行的ID为5的数据：
ID为7，8的数据行必须向下移动。虽然在这算什么事儿，但当您的数据量达到数百万行的级别之后，这就是个问题了。如果你还想要每秒处理上百次这种请求，那可真是难上加难了。
这就是GUID主键引发的问题：它是随机产生的，所以在数据插入时，随时都会涉及到数据的移动，导致插入会很缓慢，还会涉及大量不必要的磁盘活动。总结果有两点：
- 空间的浪费以及由此带来的读写效率的下降；
- 更主要的，存储的碎片化以及由此带来的读写效率严重下降。
GUID最关键的问题就是它是随机的。我们需要设计一种有规则的GUID生成方式，在之后生成的GUID类型总是比之前的要大，保证插入数据库的主键是在列表末尾追加的，这种我们称之为有序GUID。
二、GUID排序规则
在讲解有序GUID之前，我们必须先了解一下GUID在.Net中以及各个数据库中的排序规则，排序规则不一样，生成有序GUID的规则也会随之变化。
128位的GUID主要有4部分组成：Data1, Data2, Data3, and Data4，你可以看成下面这样：
11111111-2222-3333-4444-444444444444
Data1占4个字节、Data2占2个字节、 Data3占2个字节、Data4占8个字节。我们分别的对个字节编上序号：
| 序号 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Value | 11 | 11 | 11 | 11 | - | 22 | 22 | - | 33 | 33 | - | 44 | 44 | - | 44 | 44 | 44 | 44 | 44 | 44 |
GUID在.Net中的排序规则
在.Net中，GUID默认的排序过段规则是按左到右的，看下面这个示例。
1 var list = new List<Guid> {
2 new Guid("00000000-0000-0000-0000-010000000000"),
3 new Guid("00000000-0000-0000-0000-000100000000"),
4 new Guid("00000000-0000-0000-0000-000001000000"),
5 new Guid("00000000-0000-0000-0000-000000010000"),
6 new Guid("00000000-0000-0000-0000-000000000100"),
7 new Guid("00000000-0000-0000-0000-000000000001"),
8 new Guid("00000000-0000-0000-0100-000000000000"),
9 new Guid("00000000-0000-0000-0010-000000000000"),
10 new Guid("00000000-0000-0001-0000-000000000000"),
11 new Guid("00000000-0000-0100-0000-000000000000"),
12 new Guid("00000000-0001-0000-0000-000000000000"),
13 new Guid("00000000-0100-0000-0000-000000000000"),
14 new Guid("00000001-0000-0000-0000-000000000000"),
15 new Guid("00000100-0000-0000-0000-000000000000"),
16 new Guid("00010000-0000-0000-0000-000000000000"),
17 new Guid("01000000-0000-0000-0000-000000000000")
18 };
19 list.Sort();
20
21 foreach (Guid guid in list) {
22 Console.WriteLine(guid.ToString());
23 }
输出结果：
00000000-0000-0000-0000-000000000001
00000000-0000-0000-0000-000000000100
00000000-0000-0000-0000-000000010000
00000000-0000-0000-0000-000001000000
00000000-0000-0000-0000-000100000000
00000000-0000-0000-0000-010000000000
00000000-0000-0000-0010-000000000000
00000000-0000-0000-0100-000000000000
00000000-0000-0001-0000-000000000000
00000000-0000-0100-0000-000000000000
00000000-0001-0000-0000-000000000000
00000000-0100-0000-0000-000000000000
00000001-0000-0000-0000-000000000000
00000100-0000-0000-0000-000000000000
00010000-0000-0000-0000-000000000000
01000000-0000-0000-0000-000000000000
通过上面的输出结果，我们可以得到排序的权重如下：
| 序号 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 权重 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ||||
| Value | 11 | 11 | 11 | 11 | - | 22 | 22 | - | 33 | 33 | - | 44 | 44 | - | 44 | 44 | 44 | 44 | 44 | 44 |
这与数字排序规则一致，从右到左进行依次进行排序（数字越小，权重越高，排序的优先级越高）。
GUID在各个数据库中的排序规则
在SQL Server数据库中，我们有一种非常简单的方式来比较两个GUID类型的大小值（其实在SQL Server数据库中称为UniqueIdentifier类型）：
1 With UIDs As (-- 0 1 2 3 4 5 6 7 8 9 A B C D E F
2 Select ID = 1, UID = cast ('00000000-0000-0000-0000-010000000000' as uniqueidentifier)
3 Union Select ID = 2, UID = cast ('00000000-0000-0000-0000-000100000000' as uniqueidentifier)
4 Union Select ID = 3, UID = cast ('00000000-0000-0000-0000-000001000000' as uniqueidentifier)
5 Union Select ID = 4, UID = cast ('00000000-0000-0000-0000-000000010000' as uniqueidentifier)
6 Union Select ID = 5, UID = cast ('00000000-0000-0000-0000-000000000100' as uniqueidentifier)
7 Union Select ID = 6, UID = cast ('00000000-0000-0000-0000-000000000001' as uniqueidentifier)
8 Union Select ID = 7, UID = cast ('00000000-0000-0000-0100-000000000000' as uniqueidentifier)
9 Union Select ID = 8, UID = cast ('00000000-0000-0000-0010-000000000000' as uniqueidentifier)
10 Union Select ID = 9, UID = cast ('00000000-0000-0001-0000-000000000000' as uniqueidentifier)
11 Union Select ID = 10, UID = cast ('00000000-0000-0100-0000-000000000000' as uniqueidentifier)
12 Union Select ID = 11, UID = cast ('00000000-0001-0000-0000-000000000000' as uniqueidentifier)
13 Union Select ID = 12, UID = cast ('00000000-0100-0000-0000-000000000000' as uniqueidentifier)
14 Union Select ID = 13, UID = cast ('00000001-0000-0000-0000-000000000000' as uniqueidentifier)
15 Union Select ID = 14, UID = cast ('00000100-0000-0000-0000-000000000000' as uniqueidentifier)
16 Union Select ID = 15, UID = cast ('00010000-0000-0000-0000-000000000000' as uniqueidentifier)
17 Union Select ID = 16, UID = cast ('01000000-0000-0000-0000-000000000000' as uniqueidentifier)
18 )
19 Select * From UIDs Order By UID, ID
查询结果：
| ID | UID |
|---|---|
| 16 | 01000000-0000-0000-0000-000000000000 |
| 15 | 00010000-0000-0000-0000-000000000000 |
| 14 | 00000100-0000-0000-0000-000000000000 |
| 13 | 00000001-0000-0000-0000-000000000000 |
| 12 | 00000000-0100-0000-0000-000000000000 |
| 11 | 00000000-0001-0000-0000-000000000000 |
| 10 | 00000000-0000-0100-0000-000000000000 |
| 9 | 00000000-0000-0001-0000-000000000000 |
| 8 | 00000000-0000-0000-0010-000000000000 |
| 7 | 00000000-0000-0000-0100-000000000000 |
| 6 | 00000000-0000-0000-0000-000000000001 |
| 5 | 00000000-0000-0000-0000-000000000100 |
| 4 | 00000000-0000-0000-0000-000000010000 |
| 3 | 00000000-0000-0000-0000-000001000000 |
| 2 | 00000000-0000-0000-0000-000100000000 |
| 1 | 00000000-0000-0000-0000-010000000000 |
通过上面可以得于是如下结果：
- 先按每1-8从左到右进行排序；
- 接着按第9-10位从右到左进行排序；
- 最后按后11-16位从右到左进行排序;
通过分析，我们可得到如下权重列表：
| 序号 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 权重 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 7 | 8 | 1 | 2 | 3 | 4 | 5 | 6 | ||||
| Value | 11 | 11 | 11 | 11 | - | 22 | 22 | - | 33 | 33 | - | 44 | 44 | - | 44 | 44 | 44 | 44 | 44 | 44 |
在Microsoft官方文档中，有一篇文档关于GUID与uniqueidentifier的值比较：Comparing GUID and uniqueidentifier Values。
不同的数据库处理GUID的方式也是不同的：
1）在SQL Server存在内置GUID类型，没有原生GUID支持的数据库通过模拟方式来实现的；
2）在Oracle保存为raw bytes类型，具体类型为raw(16)；
3）在MySql中通常将GUID储存为char(36)的字符串形式；
关于Oracle、MySql数据库的排序规则与.Net中排序规则，不过篇章的限制，这里不再做具体的演示。在github上提供了示例SQL语句：https://gist.github.com/tangdf/f0aed064ba10bfa0050e4344b9236889。我们在这里只给出最终的结论：
小结：
- .Net中GUID的排序规则是从左到右依次进行排序，与数字排序规则一致；
- Sql Server数据库提供对GUID类型的支持，在数据库中称为
UniqueIdentifier类型，但是排序规则比较复杂：Oracle数据库未提供对GUID类型的支持，使用的是raw bytes类型保存数据raw(16)，具体类型为，排序规则与GUID在.Net中规则一致；
- 先按每1-8从左到右进行排序；
- 接着按第9-10位从右到左进行排序；
- 最后按后11-16位从右到左进行排序；
- Oracle数据库未提供对GUID类型的支持，使用的是raw bytes类型保存数据raw(16)，具体类型为，排序规则与GUID在.Net中规则一致；
- MySql数据未提供对GUID类型的支持，使用的是字符串的类型保存数据，使用是的char(36)类型，由于使用的是字符串类型，排序规则与GUID在.Net中的规则一致。
三、有序GUID
有序GUID是有规则的生成GUID，保存在之后生成的GUID类型总是比之前的要大。不过在上一节中，已经提到过各个数据库对GUID支持不一样，而且排序的规则也不一样，所以我们需要为每一个数据库提供不一致的有序GUID生成规则。
UuidCreateSequential函数
我们都知道SQL Server数据库有一个NewSequentialId()函数，用于创建有序GUID。在创建表时，可以将它设置成为GUID类型字段的默认值，在插入新增数据时自动创建主键的值（该函数只能做为字段的默认值，不能直接在SQL中调用）。
示例：
1 Create Table TestTable
2 (
3 ID UniqueIdentifier Not Null Default ( NewSequentialId() ) ,
4 Number Int
5 );
NewSequentialId()函数只能在数据库使用，不过在 Microsoft 的 MSDN 文档中有说明，NEWSEQUENTIALID 是对 Windows UuidCreateSequential 函数的包装，https://msdn.microsoft.com/zh-cn/library/ms189786(v=sql.120).aspx。这样我们可以在C#通过非托管方法调用：
1 [System.Runtime.InteropServices.DllImport("rpcrt4.dll", SetLastError = true)]
2 private static extern int UuidCreateSequential(out Guid guid);
3
4 public static Guid NewSequentialGuid()
5 {
6 const int RPC_S_OK = 0;
7
8 int result = UuidCreateSequential(out var guid);
9 if (result != RPC_S_OK) {
10 throw new System.ComponentModel.Win32Exception(System.Runtime.InteropServices.Marshal.GetLastWin32Error());
11 }
12
13 return guid;
14 }
不这个方法也存在三个问题：
- 这个方法涉及到安全问题，
UuidCreateSequential函数依赖的计算硬件，该方法的后12位其实是网卡的MAC地址。这是我电脑生成的一组有序GUID。
{A2A93393-C8DC-11E7-B133-2C56DC497A97}
{A2A93394-C8DC-11E7-B133-2C56DC497A97}
{A2A93395-C8DC-11E7-B133-2C56DC497A97}
{A2A93396-C8DC-11E7-B133-2C56DC497A97}
{A2A93397-C8DC-11E7-B133-2C56DC497A97}
{A2A93398-C8DC-11E7-B133-2C56DC497A97}
{A2A93399-C8DC-11E7-B133-2C56DC497A97}
{A2A9339A-C8DC-11E7-B133-2C56DC497A97}
{A2A9339B-C8DC-11E7-B133-2C56DC497A97}
{A2A9339C-C8DC-11E7-B133-2C56DC497A97}
这是我电脑的网卡的MAC地址：
-
由于
UuidCreateSequential函数生成的有序GUID中包括MAC地址，所以如果在服务器集群环境中，肯定存在一台服务器A上生成的有序GUID总比另一台服务器B生成要更小，服务器A产生的数据插入到数据库时，由于聚集索引的问题，总是会移动服务器B已经持久化到数据库中的数据。集群的服务器越多，产生的IO问题更严重。在服务器群集环境中，需要自行实现有序GUID。 -
UuidCreateSequential函数生成的GUID规则与SQL Server中排序的规则存在不一致，这样仍然会导致严重的IO问题，所以需要将GUID重新排序后再持久化到数据库。例如上面列出生成的GUID列表，依次生成的数据可以看出，是第4位字节在自增长，在这与任何一个数据库的排序规则都不一致；关于该函数生成的规则，可以见此链接：https://*.com/questions/5585307/sequential-guids。
下面的方法是将生成的GUID调整成为适合Sql Server使用的有序GUID（针对其它数据库支持，您可以按排序规则自行修改）：
1 [System.Runtime.InteropServices.DllImport("rpcrt4.dll", SetLastError = true)]
2 static extern int UuidCreateSequential(byte[] buffer);
3
4 static Guid NewSequentialGuid() {
5
6 byte[] raw = new byte[16];
7 if (UuidCreateSequential(raw) != 0)
8 throw new System.ComponentModel.Win32Exception(System.Runtime.InteropServices.Marshal.GetLastWin32Error());
9
10 byte[] fix = new byte[16];
11
12 // reverse 0..3
13 fix[0x0] = raw[0x3];
14 fix[0x1] = raw[0x2];
15 fix[0x2] = raw[0x1];
16 fix[0x3] = raw[0x0];
17
18 // reverse 4 & 5
19 fix[0x4] = raw[0x5];
20 fix[0x5] = raw[0x4];
21
22 //