JOIN 性能：复合键与 BigInt 主键

Question

我们有一个表将有 1 亿到 10 亿行（表名称：存档）

此表将从另一个表 Users 中引用。

存档表的主键有 2 个选项：

选项 1：dataID (bigint)

选项 2：用户 ID + 日期时间（4 字节版本）。

架构：

用户 - 用户 ID（整数）

存档 - 用户身份 - 日期时间

或

存档 - dataID（大整数）

哪个会更快？

我们不愿使用 Option#1，因为 bigint 是 8 个字节，并且有 1 亿行，这将增加分配的存储空间。

更新 好的，抱歉我忘了提，userID 和 datetime 必须是不管的，所以这就是不向表中添加另一列 dataID 的原因。

Answer 1

一些想法，但可能没有明确的解决方案：

• 如果您有十亿行，为什么不使用从 -21 亿到 +21 亿的 int？

• Userid, int, 4 bytes + smalldatetime, 4 bytes = 8 bytes, 同 bigint

• 如果您正在考虑 userid + smalldatetime，那么无论如何这肯定很有用。 如果是这样，添加一个代理“archiveID”列无论如何都会增加空间

• 是否需要按用户 ID + smalldatetime 过滤/排序？

• 确保您的模型是正确的，以后再担心 JOIN...

Answer 2

关注：使用 UserID/[small]datetime 会带来不唯一的高风险。

这是一些真实的架构。你说的是这个吗？

-- Users (regardless of Archive choice)
CREATE TABLE dbo.Users (
    userID      int           NOT NULL  IDENTITY,
    <other columns>
    CONSTRAINT <name> PRIMARY KEY CLUSTERED (userID)
)

-- Archive option 1
CREATE TABLE dbo.Archive (
    dataID      bigint        NOT NULL  IDENTITY,
    userID      int           NOT NULL,
    [datetime]  smalldatetime NOT NULL,
    <other columns>
    CONSTRAINT <name> PRIMARY KEY CLUSTERED (dataID)
)

-- Archive option 2
CREATE TABLE dbo.Archive (
    userID      int           NOT NULL,
    [datetime]  smalldatetime NOT NULL,
    <other columns>
    CONSTRAINT <name> PRIMARY KEY CLUSTERED (userID, [datetime] DESC)
)
CREATE NONCLUSTERED INDEX <name> ON dbo.Archive (
    userID,
    [datetime] DESC
)

如果这是我的决定，我肯定会选择选项 1。磁盘很便宜。

如果您选择选项 2，您可能必须在 PK 中添加一些其他列以使其独一无二，然后您的设计开始退化。

Answer 3

选项 3 有什么作用：将 dataID 设为 4 字节整数？

另外，如果我理解正确的话，存档表将从用户表中引用，因此在存档表中包含 userID 甚至没有多大意义。

Answer 4

我建议您设置一个模拟以在您的环境中验证这一点，但我的猜测是单个 bigint 通常会更快；但是，当您查询表格时，您将查询什么？

如果我正在构建一个档案库，我可能倾向于拥有一个自动增量标识字段，然后使用分区方案根据 DateTime 和可能的用户 ID 进行分区，但这取决于具体情况。