我在发表过“据库中使用自增量字段与Guid字段主键的性能对比”这篇文章后，得到博客园各园友的很多评价，大家对我的测试方法也提出一些改进的方法。让我吃惊的是一园友提出：把guid和id的测试顺序颠倒一下，看下结果。今天就再测试一下，欢迎各园友提出更好的测试方案。
1.测试环境
操作系统:windows server 2003 R2 Enterprise Edition Service Pack 2
数据库:MS SQL 2008 Express
CPU:Intel(R) Pentium(R) 4 CPU 3.40GHz
内存:DDRⅡ 667 1G
硬盘:WD 80G
2.数据库脚本
CREATE TABLE [dbo].[Table_Guid]([Guid] [uniqueidentifier] NOT NULL CONSTRAINT [DF_Table_Guid_Guid] DEFAULT (newid()),[Value] [varchar](50) COLLATE Chinese_PRC_CI_AS NULL,CONSTRAINT [PK_Table_Guid] PRIMARY KEY CLUSTERED ([Guid] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] GO CREATE TABLE [dbo].[Table_Id]([Id] [int] IDENTITY(1,1) NOT NULL,[Value] [varchar](50) COLLATE Chinese_PRC_CI_AS NULL,CONSTRAINT [PK_Table_Id] PRIMARY KEY CLUSTERED ([Id] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] GO
首先看一下测试代码：
Code
为了消除上面的顾虑，每次仅使用一种方式测试（每次都注释不使用的代码）。
1.1.自增Id的写入测试。
1.2.Guid的写入测试。
2.1.自增Id的读取到DataTable测试
2.2.Guid的读取到DataTable测试
3.1.自增Id的数据总数统计
3.2.Guid数据总数统计
4.1.自增Id的数据总数统计（手动找到第3000条数据的id,然后查询）
4.2.Guid的数据总数统计（手动找到第3000条数据的id,然后查询）
以上测试均属本人电脑上的测试。每次的测试结果都是测试好几次，然后才取其中的一组相对平均的结果。
补充（不是我不总结，其实一些实际的应用已经在上一篇中总结过了，再整理一下吧）：
1.测试的结果Guid作为主键在以上测试的性能还是优于自动增长Id的。对于Inner join的还没有测试。
2.对于使用那种类型作为主键，还要根据具体的需要。在数据库迁移或者导入数据的时候自增量字段有可能会出现重复,这无疑是一场恶梦，而Guid格式无疑是首选。但是，使用Guid格式比较复杂，对于程序高度比较麻烦，毕竟Guid比较难记。
3.自动增长的Id使用的是int型或者bigint型，它们分别占用存储空间为4个字节和8个字节，Guid是uniqueidentifier类型，它占用16个字节。从存储空间上来说，自动增长的Id更节省空间。
4.如果要搞分布式数据库的话，这自增量字段就有问题了。因为，在分布式数据库中，不同数据库的同名的表可能需要进行同步复制。一个数据库表的自增量值，就很可能与另一数据库相同表的自增量值重复了。
我个人还是比较喜欢使用Guid作主键，因为它比较唯一，不管是任务时候它都是唯一的，数据库的导入与导出都不会出现主键重复的现象。
我个人的一些问题：
1.我使用的是windows Live Writer写的文章，为了粘贴代码的方便性，我使用from Visual Studio插件粘贴代码，但是如果代码中含有中文，例如注释，粘贴后，每个汉字后面都会多出一个“？”，这个问题不知道怎么解决，我通过设置编码方式还 是不能解决问题。
2.在Windows Live Writer中怎样设置代码（打包后上传后）的下载的链接。
另外：向喜欢数据库的园友，推荐一篇：SQL Server 查询处理中的各个阶段
关于自动增长Id与Guid的介绍请参见：据库中使用自增量字段与Guid字段主键的性能对比
测试代码
