我一直致力于提高大型报告数据库的性能。
该数据库的大小为 2TB，其中一个较大的表heap具有三个非聚集索引。
每个非聚集索引都处理 Case_ID 与相关数据的组合。
然而，案例 ID 根本不是唯一的，因为每个案例条目都与 Case_ID 存储在同一个堆中。
在业务方面的查询使我了解到 Case_ID、Line_Number 和 Document_ID 的组合是唯一的。
然而，几乎所有的查询都是由日期组成的（使用datetime名为 DATE 的列）。
通常由WHERE DATE = 'xxxx-xx-xx 00:00:00.000, 或WHERE DATE > 'xxxx-xx-xx 00:00:00.000'. 在大多数情况下，Line_Number 和 Document_ID 值甚至不包含在报告中。
因此，我在堆上（在 DEV 上）创建了一个聚簇索引，以列为键datetime。
报告的性能有了相当大的提高，我的大部分测试报告的查询时间从 5 分钟减少到 3 分钟，而且我还没有看到对未按日期声明的报告有任何负面影响。
然而，我担心我看得太远了，因为我知道非唯一聚集索引很少是解决方案。我正在做的是一种有效的方法吗？或者我应该简单地索引唯一的复合键，并在列上创建覆盖索引datetime？
非聚集索引使用聚集索引键值作为返回数据的指针。如果您创建一个复合聚集索引，那么您正在使您的非聚集索引变得更大。
选择聚簇索引时，尤其是上亿行的表，尽量选择单列窄列。即在 varchar 字段上选择一个整数。
Datetime 字段为 8 个字节，相对较窄。如果您的数据按日期升序插入（例如，随着时间的推移），记录将插入到表的末尾。将根据需要添加页面和范围。
但是，如果您的数据数据散布在各处，那么随着新记录被推入现有记录之间，您最终会出现页面拆分。确保您的传入日期数据准确无误。
请注意，如果聚簇索引不是唯一的，SQL 会在内部添加一个 4 字节的“uniquifier”。
因此，选择单列聚集索引。使用 datetime 列的查询将受益匪浅，而其他索引不会受到影响。