我正在设计一个 Invoice 表，并希望帮助决定几个索引和主键。
对于主键 - 使用 GUID 对我来说听起来是个好主意，但这是否意味着子表也需要有这个 GUID 作为外键？
发票总是在创建日期使用日期范围进行过滤。因此，我计划使用一个额外的 int 列而不是 datetime 列，该列仅包含诸如“20160101”之类的日期信息，因为我认为比较 int 比 datetime 快得多并且对我有益。由于创建时间会不断增加，因此我也计划在此列上应用集群索引。这是一个好主意吗？
发票也可以根据客户查询，我应该在 CustomerID 上放置另一个索引还是与日期列组合？
对问题标题的简短回答：不。您为什么要失去将约会视为约会对象的能力。对于排序、日期函数等非常重要。
至少让您开始的一些想法，不确定在回答时是哪个 DBMS，根据我对 SQL Server 的经验回答：
1.) GUID 作为主键通常不是一个好主意。尤其不是在 SQL Server 中。Integer 主键有什么问题？是的，无论您的主键是什么，都将成为子表中的外键，因此它很大并且可能没有必要。
2.) 我会使用一个常规的日期时间列。性能方面，如果您索引良好，您应该不会注意到这里的差异。日期时间列与日期一样用途广泛。您可以向带有内置日期时间函数的 INT 列提出您无法轻松提出的问题。如果您不需要时间并且您使用的是只有 DATE 的 DBMS 或版本，您可以使用该数据类型。
3.) 是的。特别是如果 CustomerID 是一个 Customer 表的外键。好索引。是否需要在 CustomerID 和 Date 列上建立索引取决于查询的典型外观。如果您经常查询加入客户并指定日期范围，您可能会发现拥有日期是有益的。您可能会发现包含一些其他列来覆盖其他查询作为键或包含列的一部分是有益的。不过，这实际上取决于您的查询和数据。
至于在日期列上聚类。那是一件很难的事。如果这是仓库中的事实表，并且每个查询总是在一个日期范围内，那么就会有一些好处。如果这是一个操作发票表，我想您的应用程序也会以其他方式加入发票。我还想象发票被存储在其他表中的发票 ID 等查询。所以我不相信有足够的东西来确定聚簇键。我所在的学校更喜欢 OLTP 表的简单代理键。一个 InvoiceID INT（或 BIGINT，如果你真的会炸掉一个 INT）设置为一个身份列，所以它总是增加并避免页面拆分。但我不知道这里是否有明确的错误答案（嗯，有很多，但你没有提出任何一个）