首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >大容量Server 2008的关键DataType?

问大容量Server 2008的关键DataType?
EN

Stack Overflow用户
提问于 2009-05-08 14:54:39
回答 4查看 523关注 0票数 2

在为大容量数据设计数据库的过程中,我想知道主键使用什么数据类型?

将有表分区,数据库将被集群化,并将热故障转移到其他数据中心。

编辑

表-认为聊天系统的多个时间段和多个事情聊天与多个用户谈论的时间周期和事情。

指数问题是我所想的在更改数据库或DBA执行DBA操作之前

马克-我和你分享你对GUID的理解-我不喜欢用GUID进行编码。

EN

回答 4

Stack Overflow用户

回答已采纳

发布于 2009-05-20 12:58:56

有了你提供的一点点信息,我建议你使用一个BigInt,它将为你提供最多9,223,372,036,854,775,807的数据,这个数字是不可能超过的。(不要以INT开头,当超过20亿行时,可以轻松地将其更改为BigInt。这是可能的(我已经做过了),但可能要花费非常长的时间,并且涉及到严重的系统中断。

金伯利特里普有一系列出色的博客文章(http://sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx和http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-Continues.aspx),内容涉及创建聚集索引和选择主键(相关问题,但并不总是完全相同)。她的建议是,聚集索引/主键应该是:

  1. 唯一的(否则作为键无用)
  2. 窄带(键用于所有非聚集索引和外键关系)
  3. 静态(您不想更改所有相关记录)
  4. 总是增加(因此新记录总是被添加到表的末尾,而不必插入到中间)

如果您使用BigInt作为一个递增的标识作为您的键和聚集索引,那么这将满足所有四个需求。

编辑:我上面提到的金伯利(http://sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx)的文章谈到了为什么(客户端生成的) GUID是集群密钥的错误选择:

但是,一个不是顺序的GUID --就像在客户机(使用.NET)或由newid()函数(在Server中)生成的值一样--可能是一个糟糕的选择--主要是因为它在基表中创建了碎片,但也因为它的大小。这是不必要的宽(它比基于int的标识宽4倍-它可以给你20亿(实际上,40亿)独特的行)。而且,如果您需要超过20亿行,则始终可以使用bigint (8字节int)并得到263-1行。

SQL有一个名为NEWSEQUENTIALID()的函数,它允许您生成避免碎片问题的顺序GUID,但它们仍然存在不必要的宽问题。

票数 4
EN

Stack Overflow用户

发布于 2009-05-20 10:11:38

您可以始终使用uniqueidentifier,但考虑到分区/集群,我建议您查看uniqueidentifier,它将生成全局唯一的键。

票数 1
EN

Stack Overflow用户

发布于 2009-05-20 10:26:13

int往往是一种常态,除非您需要大量的数据量,并且有使用IDENTITY等的优势;如果您希望数字不可猜测或可导出,Guid有一些优势,但是如果您使用Guid (除非您自己生成一个“精梳”),您应该确保它是非聚集的(即索引,而不是农场),因为它不会增加。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/840193

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档