Question

我在SQL Server 2012中使用具有以下结构的事实表：

CREATE TABLE [dbo].[factTable] (
    [Id]            BIGINT      IDENTITY (1, 1) NOT NULL,
    [Date]          DATE        NOT NULL,
    [MinuteNumber]  SMALLINT    NOT NULL,
    [CityId]        INT         NOT NULL, /* Foreign key to dimCity */
    [Value]         DECIMAL(12, 4)  NULL
)

我在Date列上有一个聚集索引，填充因子为100.插入此表的数据几乎总是按Date和MinuteNumber的升序排列。< / p>

我想知道 - 如果在给定方案中需要Id列？它有任何性能影响吗？或者我可以安全地消除它。
我还想知道Date列上的聚集索引是否足够（将会有许多记录具有相同的日期，甚至相同的日期和相同的分钟数）或者是否更好组合多列的聚簇索引;以及这两种方法的性能和存储含义是什么？

我是新手，任何帮助都将受到高度赞赏。

Answer 1

聚集索引必须是唯一的，因此如果您决定使用DATE，那么您将需要另一个列，这些列始终是唯一的。聚集索引还可以物理地控制数据的顺序，因此密钥应该是按升序排列的密钥。再一次，你DATE似乎拥有的东西，你做对了。

但是，了解您的表将拥有多少数据以及您计划使用多少非聚簇索引会很好？由于每个非聚簇索引叶记录都包含指向聚簇索引的指针，因此一般来说，您通常不希望聚簇索引大于它必须的大小。

基本上，简单的自动整数作为聚簇索引的关键列的优点在于它有效的存储方式，它总是按顺序增加，并且它与其他对象和用例具有良好的协同作用

marc_s，这里的用户，发布了another site (link)的链接，我想你一定要查看它。

但总而言之，绝大部分时间安全的做法是保持这种简单，只需将聚簇索引放在基本的int / bigint标识列上，然后使用非聚簇索引来优化对表中特定列的搜索。这在大多数情况下都足够好了。无需复杂化事情，并且对已经运行速度超过足够快的查询寻求5％的改进。所以，问题是，您是否有理由期望标准解决方案不适用于您的情况？比如，一个巨大的数据量（在这里谈论bigint规模行，例如超过几十亿），其他性能影响（对同一数据库中其他表的复杂条件连接），或其他类似的东西？

Answer 2

在您的情况下，我可能会在标识列上创建一个非聚簇主键，以便更容易地进行FK关系管理和性能。

群集密钥位于date列，以便更快地进行范围查询。 date列还满足聚簇索引的三个基本要求：它的范围很窄（使非聚簇索引更小），它是稳定的（因为CI列的更改意味着重新编写NC索引，这是应该避免的）并且它正在增加（以避免错误的页面拆分，不在表格末尾的那些）。

WRT非唯一聚簇索引，如果SQL Server不是唯一的，它将向其添加一个uniquifier数据。

在给定方案中，事实表中是否需要/推荐Id列

2 个答案: