2

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

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

编辑

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

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

马克 - 我和你一样关心 GUID - 我不喜欢 GUID 飞来飞去的编码。

4

4 回答 4

4

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

Kimberly Tripp 有一系列关于创建聚簇索引和选择主键（相关问题，但并不总是完全相同的问题）的优秀系列博客文章（GUIDs as PRIMARY KEYs and/or the clustering key and The Clustered Index Debate Continues ） ）。她的建议是聚集索引/主键应该是：

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

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

编辑：我上面提到的 Kimberly 的文章（GUIDs as PRIMARY KEYs 和/或集群键）讨论了为什么（客户端生成的）GUID 是集群键的错误选择：

但是，一个非连续的 GUID——比如它的值在客户端（使用 .NET）或由 newid() 函数（在 SQL Server 中）生成的 GUID 可能是一个非常糟糕的选择——主要是因为碎片化它在基表中创建，但也因为它的大小。它不必要地宽（它比基于 int 的标识宽 4 倍——它可以为您提供 20 亿（实际上是 40 亿）个唯一行）。而且，如果您需要超过 20 亿行，您总是可以使用 bigint（8 字节 int）并获得 263-1 行。

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

于 2009-05-20T12:58:56.643 回答
1

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

于 2009-05-20T10:11:38.650 回答
1

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

于 2009-05-20T10:26:13.470 回答
0

我认为 int 会非常适合它。

INTEGER 的范围是 - 2147483648 到 2147483647。

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

  • MSSQL 中的表行大小限制
  • 存储+内存。想象一下，你有 10000000 行并且还在增长的表
  • 灵活性：有可用于 INT 的 T-SQL 运算符，例如 >、<、= 等...
  • GUID 未针对 ORDER BY/GROUP BY 查询和一般范围查询进行优化
于 2009-05-20T10:23:29.920 回答