Question

我们有一张表可以说是1亿到10亿行（表名：存档）

此表将从另一个表Users。

中引用

我们在Archive表上有两个主键选项：

选项1：dataID（bigint）

选项2：userID + datetime（4字节版本）。

架构：

用户 - userID（int）

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

OR

归档 - dataID（big int）

哪一个会更快？

我们正在回避使用选项＃1，因为bigint是8个字节，并且有1亿行将累积到存储分配。

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

Answer 1

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

如果你有十亿行，为什么不使用从-2.1亿到+21亿的int？
Userid，int，4个字节+ smalldatetime，4个字节= 8个字节，与bigint相同
如果您正在考虑使用userid + smalldatetime，那么无论如何这肯定是有用的。如果是这样，添加代理“archiveID”列将无论如何都会增加空间
您是否需要按userid + 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字节int？

另外，如果我理解正确，将从users表中引用归档表，因此在归档表中使用userID甚至没有意义。

Answer 4

我建议你设置一个模拟来在你的环境中验证这一点，但我的猜测是单个bigint一般会更快;但是，当您查询表时，您要查询的内容是什么？

如果我正在构建一个arhive，我可能倾向于拥有一个自动增量标识字段，然后使用分区方案来基于DateTime和可能是userid，但这将取决于环境。

JOIN性能：复合键与BigInt主键

4 个答案: