“巨大”数据库表 PK 的顺序 GUID 或 bigint

Question

我知道这类问题经常出现，但我还没有读到任何有说服力的论据来帮助我做出这个决定。请多多包涵！

我有一个巨大的数据库 - 它每天增长大约 10,000,000 条记录。数据是相关的，出于性能原因，我使用 BULK COPY 加载表。出于这个原因，我需要为行生成键，并且不能依赖 IDENTITY 列。

一个 64 位整数 - bigint - 对我来说足够宽，但为了保证唯一性，我需要一个集中式生成器来为我制作 ID。我目前有这样一个生成器服务，它允许服务保留 X 序列号并保证没有冲突。但是，这样做的结果是，我拥有的所有服务都依赖于这个集中式生成器，因此我在分发系统方面受到限制，并且对强加的其他依赖项（例如需要网络访问）不满意通过这种设计。这有时是一个问题。

我现在正在考虑使用顺序 GUID 作为我的主键（在 SQL 外部生成）。据我自己的测试确定，这些唯一的缺点是更广泛的数据类型的磁盘空间开销（由于它们在索引中的使用而加剧）。与 bigint 替代方案相比，我没有目睹任何明显的查询性能下降。使用 BULK COPY 加载表稍慢，但不会慢很多。由于我的顺序 GUID 实现，我的基于 GUID 的索引不会变得碎片化。

基本上，我想知道的是是否还有其他我可能忽略的注意事项。目前，我倾向于采取飞跃并开始使用 GUID。我绝不是数据库专家，所以我真的很感激任何指导。

Answer 1

我也有类似的情况。目前，我正在使用顺序 GUID 方法，并且没有碎片且易于生成密钥。

我注意到导致我开始迁移到 bigint 的两个缺点：

1. 空间使用情况。每个索引多 8 个字节。将其乘以 10 个左右的索引，就会造成巨大的空间浪费。
2. 列存储索引不支持 GUID。

(2) 是我的杀手。

我现在将像这样生成我的密钥：

yyMMddHH1234567890

我将使用领先的日期加小时，并在之后有一个连续的部分。这使我能够按日期对数据进行范围查询，而根本不需要任何附加索引。这对我来说是一个很好的奖励。

我将使用HiLo算法生成 bigint 的顺序部分，该算法非常适合分布式。

希望其中的一些内容能适用于您的情况。我绝对推荐使用 bigint。