不测不知道，一测吓一跳。不知道我的这个测试结果能否也会吓您一条，至少和我的想象的是有很大的差距的。
最近有两篇关于GUID和Int自增的文章，我是一直使用Int自增的，不习惯使用GUID，感觉GUID很麻烦，用着不方便，性能也比不上Int自增。但是同时我也知道，二者在性能上孰优孰劣，只是感觉和猜测，并没有做测试！我是只相信测试，不相信分析、推断的。可能是由于我一直都没有系统的学习过的原因吧，高分析总是迷迷糊糊，模棱两可的。所以我更详细测试的结果。
一直想做一下这方面的测试来着，但是比较懒了，一直没有测试，看到了两片博文，勾起了我的兴趣，呵呵，测试一回吧。
一、 测试环境
1、 硬件
可怜的笔记本，
Dell E400，Core 2 7250，
4G内存（其中2G作为虚拟硬盘），
160G物理硬盘，2G虚拟硬盘。
2、 软件
Windows 2003 Server
SQL Server 2000
二、 测试目的
1、 测试在多表关联的时候Int自增和GUID的性能对比。
主键、外键是Int自增 VS 主键、外键是GUID。
对比一下在多表关联的情况下，二者的性能如何？
疑问：聚集索引是否都要设置到哪里？
对于Int的自然是把聚集索引设置到主键上了，但是GUDI呢？没有用过GUID，不清楚了。不过不管三七二十一，测试了再说。就先把聚集索引也设置到GUID上面吧。
三、 测试步骤
1、 建立数据库
俺比较心疼硬盘，所以就在虚拟硬盘里面建立数据库了，这样添加测试数据的时间应该会快很多吧。就是测试嘛，丢了也无所谓了。
另外tempdb.mdf也被我放到虚拟硬盘里面了。
2、 建立两组测试用表。
以客户信息、合同信息为例。第一组表用Int作为主键，第二组表以GUID作为主键。字段嘛，咱们就简单一点吧。
【客户信息表】
客户ID、客户名称、地址、添加时间。
其中 客户ID 是主键、聚集索引、 Int自增。
【合同信息表】
合同ID、客户ID、合同名称、合同内容、添加时间。
其中 合同ID 是主键、聚集索引、GUID。
3、 添加测试数据。
客户信息6.5万，合同信息26.2万。每一个客户都有4条合同信息。
到了添加数据的时候才发现，客户信息表的测试数据倒是好加，但是合同信息表里的测试数据那就不好加了，因为客户ID这个外键的数据，不是那么容易设置上的。所以我就想了一个偷懒的方法。
添加第一组表的客户信息。
添加第一组表的合同信息。
修改第一组表合同信息里的客户ID。
拷贝第二组表里的客户信息。
拷贝第二组表的合同信息。
修改第二组表合同信息里的客户ID。
Code
--添加客户信息
insert into A客户信息
(
客户名称, 客户地址
)
select 客户名称, 客户地址 from A客户信息
--修改客户名称
update A客户信息 set 客户名称 = '客户名称:' + cast(客户ID as nvarchar(1000))
--添加合同信息
insert into A合同信息
(合同名称, 合同内容
)
select 合同名称, 合同内容 from A合同信息
--修改合同名称
update A合同信息 set 合同名称 = 合同名称 + cast(合同ID as nvarchar(1000))
修改客户ID，客户ID = 合同ID / 4
update A合同信息 set 客户ID = (合同ID - 1) / 4 + 1
--复制GUID用的客户信息
insert into B客户信息
(
客户ID,客户名称, 客户地址
)
select 客户ID, 客户名称, 客户地址 from A客户信息
--复制GUID用的合同信息
insert into B合同信息
(合同ID,客户ID,合同名称, 合同内容
)
select 合同ID,客户ID,合同名称, 合同内容 from A合同信息
--修改GUID的合同信息里面的客户GUID
update V_设置合同里的客户GUID set 客户GUID = 客户的客户GUID
4、 建立视图
【V_A_客户合同信息】 Int自增使用的视图
SELECT TOP 100 PERCENT b.合同ID, b.客户ID, b.合同名称, b.合同内容, b.添加时间,
a.客户名称, a.客户地址
FROM dbo.A合同信息 b INNER JOIN
dbo.A客户信息 a ON b.客户ID = a.客户ID
ORDER BY b.合同ID
【V_B_客户合同信息】 GUID使用的视图
SELECT TOP 100 PERCENT b.合同GUID, b.客户GUID, b.合同名称, b.合同内容, a.客户名称,
b.添加时间, a.客户地址, a.添加时间 AS Expr1
FROM dbo.B合同信息 b INNER JOIN
dbo.B客户信息 a ON b.客户GUID = a.客户GUID
ORDER BY b.合同GUID
5、 测试显示全部合同信息的时间。
偷懒了，就在查询分析器里面测试吧。在查询分析器里面写上 select * from V_A_客户合同信息 和 select * from V_B_客户合同信息，开始测试。
四、 测试结果
先测试Int自增的情况。重启SQL Server 服务，执行 select * from V_A_客户合同信息 五次，
第一次：50秒
第二次：21秒
第三次：27秒
第四次：23秒
第五次：18秒
在测试GUID的情况。重启SQL Server 服务，执行 select * from V_B_客户合同信息 五次，
第一次：18秒
第二次：38秒
第三次：1分21秒
第四次：35秒
第五次：15秒
对于这种结果，我是无语了。原本以为Int会比GUID快，但是好像也没快呀。测试的数据变化范围也太大了呀。我是不知道是怎么回事了。所以标题里才说：只有测试，没有分析。因为我已经没有办法分析了，我把我测试的数据库传上去了，您感兴趣的话，您可以下载一下自己测试一下，呵呵。
最后辅上四个SQL 语句的执行计划，以供参考。
奇怪，为什么加上了 top 100 执行计划就完全不一样了呢？ 这两个视图里面查询到的记录都是 262144 条记录。数据多了，为什么执行计划也变了呢，还变得这么的复杂？
希望能够有高人注意到这一点，希望能够帮忙分析一下！
补充
终于把测试数据库给传上去了，原来是文件太大了，60M，空间不够了。但是很郁闷，上传的时候没有准确的错误提示，我还以为是网速慢呢。收缩数据库，重新压缩，19M了。空间还是不够用了，没办法传了好多的Demo和 源代码了，所以这次就上传到 http://www.svnhost.cn/Download/Detail-511.shtml 这里了。
欢迎您下载看看，是不是我哪里弄错了，还是其他的什么原因。哦，对了，还需要您看一下视图【V_B_客户合同信息】里面的排序字段，现在是按照添加时间排序的。弱弱的说一下，按照添加时间排序的结果，还是十几秒的时间，并没有变慢。
我又把数据库放到了物理硬盘里面测试了一下，这次确实慢了，差距也大了，不过慢的是Int自增的表，而不是GUID的。Int自增的要把数据全都显示出来需要40到50秒，而GUID的只用了8秒到18秒。
至于CPU的占用率嘛，看看下面的截图吧，基本没怎么使用CPU。（不要说这又是虚拟硬盘造成的吧）
至于分析，哎，我是能力有限，只会简单的应用，不会理论，对原理也不熟，不对是根本就不懂原理，呵呵，所以分析的事情就请教各位高手了。
【这个是查询Int自增的时候的CPU截图，GUID的只比这个底，不比这个高。不信您自己测试，呵呵】