当前位置: 代码迷 >> Sql Server >> Guid 仍是 BigInt 苦恼
  详细解决方案

Guid 仍是 BigInt 苦恼

热度:582   发布时间:2016-04-24 20:57:02.0
Guid 还是 BigInt 苦恼
最近在网上看关于GUID还是BigInt坐住建的文章,很是苦恼,到底GUID和BIGINT谁的效率高呢,别告诉我各有优点。。。
SQL?主键

------解决方案--------------------
建议用bigint,效率应该更高..
------解决方案--------------------
USE CSDN
GO
CREATE TABLE dbo.test3
(
aa BIGINT, --8字节
bb UNIQUEIDENTIFIER, --16字节,生成的GUID无序,全球唯一
cc UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() --16字节,生成的GUID在本机自增,全球唯一(UUID)
)

/*
#1.从存储上说,bigint省空间,优选
#2.从计算上说,bigint运算能力比guid强
#3.guid的全球唯一性,是其它任何存储方式都代替不了的.迁移很方便,但同时会导致索引严重碎片.可以用newid()函数生成
#4.建议使用newsequentialid函数(只能定义在默认值中),生成时有序。微软内部会用它。
综上所述。建议: bigint->UUID->GUID
*/

------解决方案--------------------
GUID就是个坑。
尤其遇到排序的时候。。。。
------解决方案--------------------
当然是BIGINT,不过如果是高并发用BIGINT增长要好好设计一下
------解决方案--------------------
int/bigint就是在多服务器(分支机构)的同一个表的记录要汇集到(总部服务器的)一个大表时,
必须增加(分支机构id)字段了,而且关联的主键字段也要跟着变。。。。

如果分支机构和总部都是使用同一套系统(即不能增加字段),就乱了
------解决方案--------------------
引用:
那如果项目最后是否要分布部署未知,能不能使用BigINT和UID同时使用,以bigint为主键,UID为无意义标识(候补主键),所有的外键都同时使用这两个字段,也可以说是联合主键,但是不是真正意义的联合


最好别这样。主键使用的字段长度尽量取短的,Guid是16位,bigint为8位。
  相关解决方案