数据库中使用自增量字段与Guid字段作主键的性能对比(补充篇)

     数据库中使用自增量字段与Guid字段作主键的性能对比(补充篇)  

      我在发表过“据库中使用自增量字段与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的写入测试。

 image

1.2.Guid的写入测试。

image

2.1.自增Id的读取到DataTable测试

image

2.2.Guid的读取到DataTable测试

image

3.1.自增Id的数据总数统计

image

3.2.Guid数据总数统计

image

4.1.自增Id的数据总数统计(手动找到第3000条数据的id,然后查询)

image

4.2.Guid的数据总数统计(手动找到第3000条数据的id,然后查询)

image

以上测试均属本人电脑上的测试。每次的测试结果都是测试好几次,然后才取其中的一组相对平均的结果。

补充(不是我不总结,其实一些实际的应用已经在上一篇中总结过了,再整理一下吧):
      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字段主键的性能对比

      测试代码

(作者:侯垒
标签: SQL
posted @ 2009-07-29 11:43 侯垒 阅读(4217) 评论(43) 编辑 收藏

 回复 引用 查看   
#1楼 2009-07-29 11:48 温景良(Jason)      
不错
 回复 引用 查看   
#2楼 2009-07-29 12:04 zeus2      
如果Inner join呢。
 回复 引用 查看   
#3楼 2009-07-29 12:37 任力      
来支持一下兄弟,呵呵。。。
性能对比对于程序员来说是非常重要的,如果我们注意的好,会让我们写出来的程序跑的更快。
但是注重这些性能比较要注意适可而止哦,呵呵。。性能优化是无极限的。而且现实的项目中要复杂的多,影响性能的可能有很多哦。。
当然,注意这些肯定是有利无害的。。

 回复 引用   
#4楼 2009-07-29 12:37 xp000[未注册用户]
Inner Join之后接着来
Where GUID = 'xxxxxxxxxxxxxxxxxxxx'
or
Where ID = xxxxxxxxxxxxxxxx




 回复 引用 查看   
#5楼 2009-07-29 12:44 Ryan Gene      
测试结论总结好像没有嘛。。。
 回复 引用   
#6楼 2009-07-29 12:53 反反复复[未注册用户]
你测完,说明个什么问题,得出个什么结论 有必要说名一下吧。
我对一堆数据不敢兴趣。

 回复 引用 查看   
#7楼 2009-07-29 12:57 高海东      
关联多个表测试下,看看性能怎么样
 回复 引用 查看   
#8楼 2009-07-29 13:01 沉默杨仔      
非常好。支持~!~~~
 回复 引用 查看   
#9楼 2009-07-29 13:08 斯克迪亚      
我也用windows Live Writer
粘贴代码我是先粘贴到Word,再复制,再 选择性粘贴>保留所有格式 到Live Writer

 回复 引用   
#10楼 2009-07-29 13:13 yeahjob[未注册用户]
关健是多表相关连操作测试
 回复 引用 查看   
#11楼 2009-07-29 13:24 asheng      
哎 啥也没说明一下
 回复 引用   
#12楼 2009-07-29 13:31 过路人1[未注册用户]
我个人感觉两种主键类型还要考虑数据的存储,以上的测试数据量不是很大,但实际项目中会随着数据的增多,性能的表现也会有不同的,当然也有楼上说的关联查询也应该考虑进去
 回复 引用 查看   
#13楼 2009-07-29 14:39 smx      
http://cd.xtox.cn/Default.htm


关健是多表相关连操作测试

 回复 引用 查看   
#14楼 2009-07-29 14:43 小彬      
呃,结论呢?


 回复 引用 查看   
#15楼 2009-07-29 15:17 徐少侠      
多表关联的性能绝不会因为数据类型的不同而有30%以上的差异
 回复 引用 查看   
#16楼[楼主] 2009-07-29 15:35 侯垒      
@任力
非常的同意。

 回复 引用 查看   
#17楼[楼主] 2009-07-29 15:36 侯垒      
@小彬
@Ryan Gene
对于两者的取舍因为在上篇中已经提到。
既然都想直接看到。就再总结一下。

 回复 引用 查看   
#18楼[楼主] 2009-07-29 15:38 侯垒      
@斯克迪亚
关键是可以接入代码,如果代码中含有中文,每个汉字后面会出现一个“?”。

 回复 引用 查看   
#19楼 2009-07-29 15:48 青羽      
记得看过温少的一篇文章也是谈ID的。
楼主可以参考下:http://www.cnblogs.com/jobs/archive/2007/11/16/961116.html

 回复 引用 查看   
#20楼[楼主] 2009-07-29 15:54 侯垒      
@青羽
谢谢了。其它我上一篇也有这方面更详细的介绍。
http://www.cnblogs.com/houleixx/archive/2008/12/13/Id_And_Guid.html
1.自增量字段

自增量字段每次都会按顺序递增,可以保证在一个表里的主键不重复。除非超出了自增字段类型的最大值并从头递增,但这几乎不可能。使用自增量字段来做主键是非常简单的,一般只需在建表时声明自增属性即可。

自增量的值都是需要在系统中维护一个全局的数据值,每次插入数据时即对此次值进行增量取值。当在当量产生唯一标识的并发环境中,每次的增量取值都必须最此全局值加锁解锁以保证增量的唯一性。这可能是一个并发的瓶颈,会牵扯一些性能问题。

  在数据库迁移或者导入数据的时候自增量字段有可能会出现重复,这无疑是一场恶梦(本人已经深受其害).

如果要搞分布式数据库的话,这自增量字段就有问题了。因为,在分布式数据库中,不同数据库的同名的表可能需要进行同步复制。一个数据库表的自增量值,就很可能与另一数据库相同表的自增量值重复了。

  2.uniqueidentifier(Guid)字段

   在MS Sql 数据库中可以在建立表结构是指定字段类型为uniqueidentifier,并且其默认值可以使用NewID()来生成唯一的Guid(全局唯一标识符).使用NewID生成的比较随机,如果是SQL 2005可以使用NewSequentialid()来顺序生成,在此为了兼顾使用SQL 2000使用了NewID().

  Guid:指在一台机器上生成的数字,它保证对在同一时空中的所有机器都是唯一的,其算法是通过以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字生成。其格式为:04755396-9A29-4B8C-A38D-00042C1B9028.

   Guid的优点就是生成的id比较唯一,不管是导出数据还是做分步开发都不会出现问题.然而它生成的id比较长,占用的数据库空间也比较多,随着外存价格的下降,这个也无需考虑.另外Guid不便于记忆,在这方面不如自动增量字段,在作调试程序的时候不太方便。

 回复 引用 查看   
#21楼 2009-07-29 16:00 Kevin Zou      
結論以及關聯時的性能
 回复 引用 查看   
#22楼 2009-07-29 18:32 JacksonLin      
你做的测试之前有人做过,而且更完整
 回复 引用 查看   
#23楼 2009-07-29 18:53 Vincent Yang      
@侯垒
为何迁移的时候会出现重复呢?

 回复 引用 查看   
#24楼[楼主] 2009-07-29 19:01 侯垒      
@Vincent Yang

每个数据表都使用自动编号,都是从0开始的。而另一个数据表也是从0开始的,如果将一个数据表中的数据向另一个数据表中导入的话,就重复了。

 回复 引用   
#25楼 2009-07-29 21:35 bbisky[未注册用户]
差别不大,各取所需吧,我目前做的系统都是自增int, 最近准备做SSO,可能真的需要guid了 :)
 回复 引用 查看   
#26楼 2009-07-29 21:41 巴山游子      
对于已经发展到 SQL 2008 了的数据库引擎,单表查询,其性能应该 不会有太大问题。
最关键的是 多表关联的时候。再者,多表关联的时候,索引建立 与使用索引可能又是主要的。

 回复 引用 查看   
#27楼 2009-07-29 22:17 人生就是赌      
有没有遇到 id between 3000 and 4000的情况?
 回复 引用   
#28楼 2009-07-30 09:01 zzzzz[未注册用户]
用guid分页怎么分?
 回复 引用 查看   
#29楼[楼主] 2009-07-30 09:12 侯垒      
@zzzzz
分页与使用id没有关系吧。
难道你分页使用的是id的大小在那个范围的。那如果有数据被删除了,id不就不连续了。

 回复 引用 查看   
#30楼 2009-07-30 09:16 yzlhccdec      
期待你的join测试
 回复 引用 查看   
#31楼 2009-07-30 09:30 人生就是赌      
引用侯垒:
@zzzzz
分页与使用id没有关系吧。
难道你分页使用的是id的大小在那个范围的。那如果有数据被删除了,id不就不连续了。

使用top 分页方式,是不需要id连续的

 回复 引用 查看   
#32楼 2009-07-30 10:06 深蓝      
“测试的结果Guid作为主键在以上测试的性能还是优于自动增长Id的。”这句话我不敢认同,从数据库的内部结构来说,GUID没有任何理由会比自增ID快。由于GUID比INT要大,应该只会比INT类型要慢才对。
 回复 引用   
#33楼 2009-07-30 10:22 guest[未注册用户]
楼主的第2点和第4点,你觉得真的是问题吗?不要道听途说抄袭别人观点,有病的看法你也抄,那是你的问题,不是别人的.我敢说你根本没有试过.
 回复 引用 查看   
#34楼[楼主] 2009-07-30 10:30 侯垒      
@guest
分布式开发,我确实是没有开发过。
但是是,对于数据的导入我确实是遇到过。
尤其是在有关联的情况下,数据库的导入与导出。把关系都弄丢了。害得我手动修改过来的。

 回复 引用 查看   
#35楼[楼主] 2009-07-30 10:34 侯垒      
@人生就是赌
分页与id确实是没有关系到的。

 回复 引用 查看   
#36楼 2009-07-30 10:50 Conan304      
感谢楼主重新测试。我就是提出要重新测试的那个。
这次测试就严谨很多了。

 回复 引用 查看   
#37楼 2009-07-30 10:59 Conan304      
 回复 引用 查看   
#38楼[楼主] 2009-07-30 11:29 侯垒      
@Conan304
谢谢,看了他的测试,感觉我的测试还不够,我测试的还不够全面。我只测试了根据id的查询,没有根据其它条件的查询。

 回复 引用 查看   
#39楼 2009-07-30 13:17 Keep Walking      
哎,测试没测试到点子上
 回复 引用 查看   
#40楼 2009-07-30 13:19 Keep Walking      
先不要去测试,就知道你这个是错误的结论!
不过楼主的实践精神可嘉

 回复 引用 查看   
#41楼 2009-07-30 13:43 Keep Walking      
http://www.cnblogs.com/perfectdesign/archive/2009/07/30/1534978.html 这是我对楼主的文章的分析,大家可以参看一下我的观点
 回复 引用 查看   
#42楼 2009-11-25 14:59 恒源      
楼主应该使用查询分析器来测试吧,还可以看到计划执行情况。
 回复 引用 查看   
#43楼 2011-12-26 14:18 wm41      
自增长导入导出也没什么大问题。
场景是:A库的A表(AA),需要导入到B库的A表。(BA)
AA->BA
先清空BA,然后导入AA
可以参考:SET IDENTITY_INSERT

Powered by: holly