我知道这类问题经常出现，但我还没有读到任何有说服力的论据来帮助我做出这个决定。请多多包涵！
我有一个巨大的数据库 - 它每天增长大约 10,000,000 条记录。数据是相关的，出于性能原因，我使用 BULK COPY 加载表。出于这个原因，我需要为行生成键，并且不能依赖 IDENTITY 列。
一个 64 位整数 - bigint - 对我来说足够宽，但为了保证唯一性，我需要一个集中式生成器来为我制作 ID。我目前有这样一个生成器服务，它允许服务保留 X 序列号并保证没有冲突。但是，这样做的结果是，我拥有的所有服务都依赖于这个集中式生成器，因此我在分发系统方面受到限制，并且对强加的其他依赖项（例如需要网络访问）不满意通过这种设计。这有时是一个问题。
我现在正在考虑使用顺序 GUID 作为我的主键（在 SQL 外部生成）。据我自己的测试确定，这些唯一的缺点是更广泛的数据类型的磁盘空间开销（由于它们在索引中的使用而加剧）。与 bigint 替代方案相比，我没有目睹任何明显的查询性能下降。使用 BULK COPY 加载表稍慢，但不会慢很多。由于我的顺序 GUID 实现，我的基于 GUID 的索引不会变得碎片化。
基本上，我想知道的是是否还有其他我可能忽略的注意事项。目前，我倾向于采取飞跃并开始使用 GUID。我绝不是数据库专家，所以我真的很感激任何指导。
在运行了一个相当大的查询之后，执行计划给了我一个缺失的索引建议，其形式如下：
(时间戳) INCLUDE (CustomerID, EventID, ID, EmployeeID)
这似乎是一个覆盖索引（INCLUDE 列都是主键（ID）或外键）。但是，我的查询 WHERE 子句是按时间戳、客户 ID 和事件 ID 进行过滤的。我不知道为什么这些没有包含在索引的主要部分中。
所以我的问题是，使用上面建议的索引有什么不同，或者我认为是更好的选择；
（时间戳、客户 ID、事件 ID）包括（ID、员工 ID）
我的理解是，这仍将允许仅时间戳索引查找，但还将通过在主要部分中包含客户和事件 ID（已过滤）来进一步帮助我的查询。
我认为这与“主要”部分的宽度有关 - 仅供参考，时间戳是 datetime2(0)，CustomerID 是 int，EventID 是一个字节。
我目前正在测试这个，但这是一个巨大的表 - 超过 1,000,000,000 行 - 比较索引需要时间。那个，我想更多地了解这个。
谢谢。