用guid来代替自增序列做为数据库主键会影响数据库的性能吗?原因是我们一般只要作为数据库主键的话,都把这个主键设为聚集索引聚集索引的物理存储结构是按照主键的排序存储的,如果按照以前的自增序列来做为主健(比如1,2,3)的话,由于每次新增的序列都是最大的,所以这条新增的记录会排在实际存储的末尾但是如果用guid的话,由于产生的guid是随意的,所以每次新增记录的时候都会不确定的插入到存储位置上,老是做插入的话,物理存储上的记录要重排,这样感觉就影响性能了为什么我们用guid是因为插入数据简单
比如要同时插入a表和b表记录,a表和b表是一对多关系,如果要出入b表记录的话,每次要先读取a表的新增那个主键的值. 而且这样做感觉要是用户多的话,并发很容易出问题

解决方案 »

  1.   

    为什么我们用guid是因为插入数据简单
    要是使用自增序列做为主键的话,
    比如要同时插入a表和b表记录,a表和b表是一对多关系,如果要出入b表记录的话,每次要先读取a表的新增那个主键的值. 而且这样做感觉要是用户多的话,并发很容易出问题用guid就简单了,随即产生一个id就可以了
      

  2.   

    用guid来代替自增序列做为数据库主键会影响数据库的性能吗?不会影响用于主键是不错的方法
      

  3.   

    如果不是特别需要,不建议使用GUID做主键。GUID合并数据确实比较方便,但是另外一方面,数据容量增加,数据无意义,且效率比自增低等。
      

  4.   

    你 select * from ... where Id=8712
    时会慢另外 插入时 会重建索引 和int型 有差别
      

  5.   

    比如要同时插入a表和b表记录,a表和b表是一对多关系,如果要出入b表记录的话,每次要先读取a表的新增那个主键的值. 而且这样做感觉要是用户多的话,并发很容易出问题
    每次要先读取a表的新增那个主键的值??? 不明白用 SELECT @@IDENTITY 不会有多用户的 问题 阿