0

我在 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
)

我在填充因子为 100 的列上有一个聚集索引。插入到该表中的数据几乎总是按和Date的升序排列。DateMinuteNumber

  1. 我想知道 - 在给定的场景中是否需要使用 Id 列？它有任何性能影响吗？或者我可以安全地消除它。

  2. 我还想知道在Date列上具有聚集索引是否就足够了（会有许多记录具有相同的日期，甚至相同的日期和相同的分钟数），还是有一个组合多个列的聚集索引更好；两种方法对性能和存储的影响是什么？

我是新手，任何帮助将不胜感激。

4

2 回答 2

1

聚集索引必须是唯一的，因此如果您决定使用 DATE，您将需要另一个列，它们一起始终是唯一的。聚集索引还可以物理控制数据的顺序，因此键应该是始终按升序排列的键。同样，您的 DATE 似乎拥有的东西，您做对了。

但是，最好知道您的表将拥有多少数据，以及您计划使用多少非聚集索引？由于每个非聚集索引叶记录都包含一个指向聚集索引的指针，所以一般来说，您不希望聚集索引比它必须的大。

基本上，一个简单的自动整数作为聚集索引的键列的优点是它在存储方面是有效的，它总是按顺序增加，并且它与其他对象和用例也有很好的协同作用。

marc_s，这里的用户，发布了另一个站点的链接（链接），我认为您一定要检查一下。

但总而言之，大多数情况下安全的赌注是保持简单，只需在基本 int / bigint 标识列上放置一个聚集索引，然后使用非聚集索引来优化对表中特定列的搜索。在大多数情况下，这已经足够好了。无需使事情复杂化，并在已经运行得足够快的查询上寻找 5% 的改进。所以，问题是，您是否有任何理由期望标准解决方案不适用于您的情况？比如，大量的数据（这里说的是 bigint 规模的行，例如超过数十亿），其他性能影响（复杂的条件连接到同一数据库中的其他表），或者其他类似的东西？

于 2014-05-02T06:48:03.680 回答
0

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

聚集键将在date列上，以允许更快的范围查询。该date列还满足聚集索引的三个基本要求：窄（使非聚集索引更小）、稳定（因为 CI 列的更改也意味着重新洗牌 NC 索引，这是应该避免的）并且它正在增加（为了避免错误的页面拆分，那些不在表末尾的）。

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

于 2014-05-02T13:41:42.283 回答