Guid 仍是 BigInt 苦恼

2013-08-04

Guid 还是 BigInt苦恼最近在网上看关于GUID还是BigInt坐住建的文章，很是苦恼，到底GUID和BIGINT谁的效率高

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位。

热点排行

SQL Server

Guid 仍是 BigInt 苦恼