当前位置: 代码迷 >> Sql Server >> guid的效率有关问题
  详细解决方案

guid的效率有关问题

热度:21   发布时间:2016-04-27 17:05:25.0
guid的效率问题
guid做相等运算的时候,效率跟int做相等运算比哪个效率高,差别大概有多大。
哪位大侠给一个经验,多谢

------解决方案--------------------
--来自百度

1.是否要采用GUID作为主键 

用GUID作主键有它的优势与不足.优势是GUID具有唯一性,在任何情况下,可以产生全球唯一的值.这是GUID最大的优势,也方便数据导入,比如要求从另一个系统中把数据导入进来,那么,不用担心,导入时,会导致主键冲突.不足是GUID值太复杂.不易记忆,因为有时,难免我们会用记录的方式,来进行记录判断.而且数据太长,影响数据库效率.GUID的产生不是以一定的次序产生,对于按主键物理排序的数据库来说,如果在记录的前部插入一条记录,可能会导致后面N次方的数据条数后移.这将导致数据插入效率.因此GUID的采用应该要慎重. 
2.是否要采用int型作为主键 

以前大家都采用int型,都是出来主键都是数字导致的.其实我们也明白.并不是只是数字的东西就是数字型的.比如电话号码等.因此对于主键,采用int型的优势是速度快,插入,查询时都可能会比其他的方式快.但我这种快的效果也未必有多明显,比如以varchar(15)为例,物理主键排序的数据,会自动以主键进行物理数据排序.因此,就算是字符型的数据,在插入时也会插入到相应的物理位置上,也就是说,在插入时可能会影响一些速度.但在以后的查询中,速度影响不会太明显.而我要说的,不采用int型作为主键,不是说,里面不存数据.我还是建议大家在主键中存放数字,这样的排序比较要比夹杂字母的排序来的快,之所以要采用字符型,也是为以后的数据导入作准备,有一天,会要求从其他表导入数据时,可以在导入数据的主键上加一个特定字母来避免与原主键冲突.比如在导入数据的主键前加一个"N"字母.这也就不用担心,要求导入数据表中的主键是数字型还是字符型了.
------解决方案--------------------
http://social.technet.microsoft.com/Forums/es-ES/sqlservermanagementzhcht/thread/52c45cf0-78d6-4ce3-9bb5-6a663dcf4129

看看这个
------解决方案--------------------
http://blog.csdn.net/jinxbin/archive/2008/05/29/2493668.aspx
SQL code
在数据库表设计时,许多人为采用INT类型还是GUID(uniqueidentifyer)作为主键争论不休,有认为int型字段好的,有认为GUID好的,很多时候的焦点集中在效率上。为了弄清事实真相,我想还是要以实验来进行测试为准。以下就是为了测试插入效率而写的一段脚本。测试环境是:Xeon 1.6/2G内存 win2003/sqlserver2005 企业版。测试脚本:--测试无主键/Identity/Uniqueidentifier/varchar类型主键插入表时的效率set nocount ondeclare @now datetime,@i intset @i=1set @now=getdate()Create table  test1(nopkey int,col uniqueidentifier )while @i<10000000Begin    insert into test1 values (1,newid())    set @[email protected]+1endPrint'新表无主键插入100万条数据所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'set @i=1set @now=getdate()while @i<10000 Begin    insert into test1 values (1,newid())    set @[email protected]+1endPrint'100万行中再插入10000条数据时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'GOCreate table Test2(pkey int identity(1,1) primary key , col uniqueidentifier default(newid()))declare @now datetime,@i intset @i=1set @now=getdate()while @i<1000000Begin    insert into test2(col) values (newid())    set @[email protected]+1endPrint '新表以int为主键插入100万条数据所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'set @i=1set @now=getdate()while @i<10000Begin    insert into test2(col) values (newid())    set @[email protected]+1endPrint'100万行中再插入10000条数据所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'GOCreate table test3(Pkey uniqueidentifier Primary key, col int)declare @now datetime,@i intset @i=1set @now=getdate()while @i<1000000Begin    insert into test3 values (newid(),3)    set @[email protected]+1endPrint '新表以uniqueidentifier主键插入100万条数据所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'set @i=1set @now=getdate()while @i<10000Begin    insert into test3 values (newid(),3)    set @[email protected]+1endPrint'100万行中再插入10000条数据所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'GOCreate table test4(Pkey varchar(36) Primary key, col int)declare @now datetime,@i intset @i=1set @now=getdate()while @i<1000000Begin    insert into test4 values (convert(varchar(36),newid()),3)    set @[email protected]+1endPrint '新表以varchar(36)类型为主键插入100万条数据:所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'set @i=1set @now=getdate()while @i<10000Begin    insert into test4 values (convert(varchar(36),newid()),3)    set @[email protected]+1endPrint'100万行中再插入10000条数据所耗时间:'+convert(varchar(200),datediff(ms,@now,Getdate()))+'毫秒'GOdrop table test1drop table test2drop table test3drop table test4运行测试结果如下: 新表无主键插入100万条数据所耗时间:1212856毫秒100万行中再插入10000条数据时间:19360毫秒新表以int为主键插入100万条数据所耗时间:111623毫秒100万行中再插入10000条数据所耗时间:1110毫秒新表以uniqueidentifier主键插入100万条数据所耗时间:118753毫秒100万行中再插入10000条数据所耗时间:1153毫秒新表以varchar(36)类型为主键插入100万条数据所耗时间:132830毫秒100万行中再插入10000条数据所耗时间:1263毫秒 经过多次测试,均为相应结果,可见在插入表时,对于无主键和有主键的表来说,无主键的表其插入效率最低,其次是Varchar,uniqueidentifier和int 从测试结果看,int类型和uniqueidentifier类型的插入时间相差无几,在2005下如果插入一两条记录的情况下应该是没有什么影响,而采用uniq这种类型的字段,在编程取ID和转移数据方面有着很大的优势,至于它占用空间比int类型要多一些,这对于本身就是超大的数据库而言应该不是太大问题。 本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/jinxbin/archive/2008/05/29/2493668.aspx