桌子大小重要吗？

Question

我有一个这样的表（虽然有更多的列）：

CREATE TABLE [dbo].[MyTable](
    [SnapKey] [int] NOT NULL,
    [SnapDt] [smalldatetime] NOT NULL,
    [Company] [varchar](4) NOT NULL,
    [ProfitCenter] [varchar](10) NOT NULL,
    [CostCenter] [varchar](10) NOT NULL,
) ON [MyPartition]([SnapKey])

CREATE CLUSTERED INDEX [IDX1] ON [dbo].[MyTable]
(
    [SnapKey] ASC
)

表在SnapKey上分区。SnapKey 是 SnapDt 的日期部分，以整数形式存储，例如 20160131 和 20160229。

每个分区仅包含 1 个 SnapKey。对于每个 SnapKey 分区，我有大约 500 万行。目前我只在我的表中保留每个月的最后一天。

我总是使用 SnapKey 进行查询。数据不会发生更新。对于每一天，数据都会填充到表格中，然后我们会在当月运行一些报告。

问题：如果我每月将数据保留 6 天，而不是每月 1 天，我的查询执行速度会变慢吗？

我找不到任何明确的答案，所以我试图用数据填充表格，但我的存储空间用完了，所以我决定问你，看看是否有任何理论上的解释。

澄清

通过再存储 5 天，我们将存储 6 倍的数据（用于历史报告）。我们将保留每月的最后 6 天，而不是仅保留最后一天。

我们的查询不会改变，我们的报告仍然超过 1 天（一个 SnapKey）。

我们每月有一个 SnapKey。现在我们有

CREATE TABLE [dbo].[MyTable](
    [SnapKey] [int] NOT NULL,
    [SnapDt] [smalldatetime] NOT NULL,
    [Company] [varchar](4) NOT NULL,
    [ProfitCenter] [varchar](10) NOT NULL,
    [CostCenter] [varchar](10) NOT NULL,
) ON [MyPartition]([SnapKey])

CREATE CLUSTERED INDEX [IDX1] ON [dbo].[MyTable]
(
    [SnapKey] ASC
)

...等等。每个月末一个 SnapKey。

再过 5 天，SnapKey 将如下所示：

20160131
20160229
20160330

您会看到我们存储了 6 倍的数据，但在我们的查询中仍然只处理一个 SnapKey。这意味着我们总是有：

WHERE SnapKey = xxxxxxxx

在我们所有的查询中。

Answer 1

如果我每月保留数据 6 天，而不是每月 1 天，我的查询执行速度是否会变慢？

这取决于。

否- 如果您运行与以前完全相同的查询（根本无法访问新数据）。

SQL Server 的分区实现为每个分区创建一个单独的行集，因此当您创建分区索引时，它会为每个分区创建一个单独的 b 树结构（请注意，分区堆也存在）。

因此，从现有分区的角度来看，简单地添加更多分区不会改变任何内容 - 索引完全相同。您的查询仅访问单个分区，因此没有任何变化。

也许- 如果您在任何阶段查询新数据。将新数据放入内存可能会取代原始查询所需的数据，具体取决于您拥有的内存量。如果更改导致新的物理 I/O，您将​​看到对性能的影响，其严重程度取决于存储子系统的功能。

* 产品文档中很多地方都提到了这一点，例如：

• 聚集索引结构
• 非聚集索引结构
• 堆结构

从这些链接：

当聚集索引具有多个分区时，每个分区都有一个 B 树结构，其中包含该特定分区的数据。
当非聚集索引具有多个分区时，每个分区都有一个 B 树结构，其中包含该特定分区的索引行。
当堆具有多个分区时，每个分区都有一个堆结构，其中包含该特定分区的数据。

您还可以通过查看系统目录视图（例如sys.partitions ）来亲自探索这一点，该视图显示包含特定分区的行的结构的hobt_id （堆或 b 树 id）。