大容量 SQL Server 2008 的关键数据类型？答案

【问题标题】：Key DataType for a high volume SQL Server 2008?大容量 SQL Server 2008 的关键数据类型？
【发布时间】：2009-05-08 14:54:39
【问题描述】：

我正在为大量数据设计数据库，我想知道主键使用什么数据类型？

将进行表分区，数据库最终将被集群化，并将热故障转移到备用数据中心。

编辑

表格 - 考虑多个时间段和多个事情的聊天系统与多个用户聊天时间段和事情。

我正在考虑的是指数问题 - 即某些东西可能会在短时间内生成数十亿行。即在我们可以更改数据库或 DBA 做 DBA 事情之前

马克 - 我和你一样关心 GUID - 我不喜欢到处乱跑的 GUID 编码。

【问题讨论】：

表中的预期行数是多少？

标签： sql-server-2008 star-schema primary-key-design

【解决方案1】：

仅凭您提供的一点点信息，我建议您使用 BigInt，这将使您达到 9,223,372,036,854,775,807，这是您永远不可能超过的数字。（不要从 INT 开始，并认为当您超过 20 亿行时您可以轻松地将其更改为 BigInt。这是可能的（我已经做到了），但可能需要很长时间，并且涉及重大的系统中断。）

Kimberly Tripp 有关于创建聚簇索引和选择主键（相关问题，但并不总是完全相同）。她的建议是聚集索引/主键应该是：

唯一（否则无用作为键）
窄（键用于所有非聚集索引和外键关系）
静态（您不想更改所有相关记录）
总是增加（所以新记录总是被添加到表的末尾，而不必插入到中间）

如果您将 BigInt 用作键和聚集索引的递增标识，则应该满足所有这四个要求。

编辑：我在上面提到的 Kimberly 的文章 (GUIDs as PRIMARY KEYs and/or the clustering key) 谈到了为什么（客户端生成的）GUID 对于集群密钥来说是一个不好的选择：

但是，一个非连续的 GUID - 像一个有它的价值观的人在客户端生成（使用 .NET）或由 newid() 函数生成（在 SQL Server 中）可能非常糟糕选择——主要是因为它在基表还因为它尺寸。它不必要的宽（它是 4 比基于 int 的身份宽倍 - 这可以给你 20 亿（真的，40 亿）独特的行）。和，如果你需要超过 20 亿总是可以使用 bigint（8 字节 int) 并获得 263-1 行。

SQL 有一个名为 NEWSEQUENTIALID() 的函数，可让您生成避免碎片问题的顺序 GUID，但它们仍然存在过宽的问题。

【讨论】：

嗨，布拉德 - 感谢您提供详细的回答 - 我将把它开放到下周，我希望其他人投票支持它，因为它目前通过问题回答。只是想说声谢谢。

【解决方案2】：

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

【讨论】：

【解决方案3】：

除非您需要大量数据，否则int往往是常态，并且具有使用IDENTITY等的优势；如果您希望数字不可猜测或可导出，Guid 具有一些优势，但如果您使用 Guid（除非您自己将其生成为“梳理”），您应该确保它是非集群的（索引，那是；不是农场），因为它不会是增量的。

【讨论】：

【解决方案4】：

我认为 int 会非常适合它。

INTEGER 的范围是 - 2147483648 到 2147483647。

您也可以使用 UniqueIdentifier (GUID)，但在这种情况下

MSSQL 中的表行大小限制
存储 + 内存。想象一下，您有 10000000 行并且还在不断增长的表
灵活性：有可用于 INT 的 T-SQL 运算符，例如 >、
GUID 未针对 ORDER BY/GROUP BY 查询和一般范围查询进行优化

【讨论】：