GUID做主键，且默认为聚集索引，这个主键再在数据库中是怎么存放的？

[WYhack]

看见一个数据库中时GUID做主键，聚集索引默认为主键（这个GUID）

但是这个GUID是自动生成的，应该来说是没有规律的，而聚集索引是顺序存放的

GUID做主键，且为聚集索引，的确是按GUID“大小”顺序存放的

我自己做了下测试，却是是这样的，如下，

但事实上我看到的那个数据库中（GUID做主键，且为聚集索引），数据的默认存放并不是按GUID的大小存放的，而是随机存放的，就是默认的存放顺序GUID第一个字符顺序无关。但是我select * from tablename order by ID的时候，竟然还是默认那个顺序（不加order by一样的顺序），到底是怎么回事呢？

还有一个问题就是，ＧＵＩＤ做主键这样会不会引起叶分裂呢（page split）

declare @i int
set @i=0
while @i<100
begin
insert into Test values (NEWID(),'aaaa')
set @i=@i+1
end

--结果如下

02CED1BC-76A3-4604-9853-564539A62A96	aaaa
0341510F-B599-4084-96CB-74DFF5021429	aaaa
0668ABCB-120A-465B-B8E1-6D1FCF9599E4	aaaa
078641B6-7598-4632-B97F-1ABCF6508F3A	aaaa
0ACD20ED-57CF-4A6D-BEA3-883E9E4C930D	aaaa
0EFFD408-FA6D-4C62-BA43-18F2AE092845	aaaa
0F51747F-6BDE-4F55-90C7-B7AFAD90C8BB	aaaa
10386C69-50A4-4A41-8D05-81EF9BAFAA98	aaaa
113FE204-494A-4303-B6DE-B5B381C94B29	aaaa
12384E03-8383-4C0E-8FC8-8E5FD65074BB	aaaa
1390D786-C07B-49A0-BAC2-9D17C012BE76	aaaa
14B42532-5CCD-4397-837D-86421FC36165	aaaa
15BDD842-95D5-43BE-A943-15E4A029F5EF	aaaa
16178FBD-6698-4398-B15C-CA1F793A6EB0	aaaa
1800EC09-8B19-443E-B5EB-53500B732123	aaaa
1C96B362-7F4D-49EB-9AED-01BA97A5BA72	aaaa
1EE53FF0-E6DF-4B57-8B1F-432472AB0C04	aaaa
20921CC3-4EB3-40DF-A5F5-EE9FAA72461F	aaaa
22215930-0810-463A-83EF-7152D6691621	aaaa
26E5B5BB-6E55-47AF-AB70-E95ED66B4BDB	aaaa
27B0E82F-DFEF-4353-9150-6BA96AEAFC24	aaaa
28C8647F-06D7-487F-90AA-920FBFB7ED05	aaaa
2CE36174-9B1E-472F-BE8D-D5CF160F1F31	aaaa
2FDD119C-6E96-422D-8A39-781449552231	aaaa
30490DCB-69B3-461C-A30D-32DCE93B6CF9	aaaa
33213377-5254-45DF-8FB4-6B5FF075CACE	aaaa
353BAF1F-1873-4F04-AFFE-1582094F5DB4	aaaa
3747C710-AE43-4842-A649-70FB4938C7C3	aaaa
393E766A-26E9-4BFE-A935-E67541B886DD	aaaa
396D367B-9EB5-44D5-9F86-66239C198598	aaaa
3F0E76FE-6655-489D-BA5E-ABA70B34EF1F	aaaa
40169B21-8B07-4718-B30A-46F8608534B3	aaaa
420FB73F-C880-4055-825C-1F513B912AB6	aaaa
469DFD96-6D33-4520-8B5F-093A02BD1176	aaaa
47CF7608-B414-49D3-9EEA-8169DB6F4BAE	aaaa
483428EE-153D-4BBB-8FC2-B2641C4D7940	aaaa
4C65A723-BBC4-4E59-8235-AB6B7FEE7D9B	aaaa
4D85821D-C6A5-4D4C-9DF0-4A2630951133	aaaa
58B76DC2-0703-4C95-AFC1-7BD95D70AB4A	aaaa
5A159F90-77DC-444A-AF84-9C85BD0535B8	aaaa
61A14EAF-6A60-41CF-B1AC-09EE12FD1181	aaaa
62562688-4E7D-4611-8BBA-6FAE7709E5E6	aaaa
62D9A0A5-A987-4A3C-9651-E54F3300856B	aaaa
69B4E5A5-019C-45A4-994D-4A3FAAA13817	aaaa
………………
F8291561-16F1-490D-B51B-4BEE0436E0E7	aaaa
F8EED731-34A5-439D-A48F-9730CDC2EE49	aaaa
FB5ED5D8-3AEC-4D06-9984-AAD7BBC918D8	aaaa
FE313DE3-CEBB-49F7-83D6-7A8A7CDB6487	aaaa

[WYhack]

我搞错了

当我把ＩＤ设置为字符类型时，他是按照ＧＵＩＤ的顺序排序的

当我把ＩＤ设置为uniqueidentifier时，ＧＵＩＤ的排序就没有规律了

那么这个ＩＤ到底是怎么算出的并且为什么按这个顺序呢？

但是这里面的规律又在哪里呢？

[WYhack]

1C96B362-7F4D-49EB-9AED-01BA97A5BA72	aaaa
8BBD741D-8002-48FC-A0EF-03D1B6BE2F5D	aaaa
AC64178D-1467-459D-8914-03FC6FC0EBF2	aaaa
D36BAC19-892C-4E52-B194-058687357177	aaaa
E2FCAF81-1CDD-42F9-B99D-079B520444E6	aaaa
B80B4724-522A-426D-A4F3-08E6BB4C2AB1	aaaa
469DFD96-6D33-4520-8B5F-093A02BD1176	aaaa
61A14EAF-6A60-41CF-B1AC-09EE12FD1181	aaaa
CE2B6E74-C44D-4CBF-BB30-0B49BEFFEEB4	aaaa
353BAF1F-1873-4F04-AFFE-1582094F5DB4	aaaa
7DE8BA5A-EFA6-4A01-8FE6-15DFABF8C439	aaaa
15BDD842-95D5-43BE-A943-15E4A029F5EF	aaaa
0EFFD408-FA6D-4C62-BA43-18F2AE092845	aaaa
……
842605D5-9C78-4397-91CC-FC8DC76A47A1	aaaa
B4BBA3B7-F11D-45E1-A637-FD27EF88E159	aaaa

[WYhack]

[Quote=引用 4 楼 haiwer 的回复:]

这样测试就明白了


SQL code
CREATE TABLE test(
id uniqueidentifier not null,
v nvarchar(20),
CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED
(
[id] ASC
)
)

insert test select newid(),'aaa'
inse……
[/Quote]

谢谢 海阔天空

[昵称被占用了]

1、GUID是有大小的，聚集索引也是按这个大小排序的，只是你把他转成字符显示（做不到不转能显示）的时候，词虚拟看不出来而已
2、ＧＵＩＤ做聚集索引（不一定主键）会引起叶分裂，所以说这个设置并不合理，数据量大很危险，建议改用一个时间字段或者其他增长的字段

[昵称被占用了]

这样测试就明白了

CREATE TABLE test(
	id uniqueidentifier not null,
	v nvarchar(20),
 CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)
)

insert test select newid(),'aaa'
insert test select newid(),'bbb'
insert test select newid(),'ccc'
insert test select newid(),'ddd'

select * ,cast(id as varbinary(16))
from test
order by id

drop table test

[haitao]

好像有改进版的guid，有顺序了
sql2008才有

——请使用过的介绍一下