对大表进行分区并没有提高性能，为什么？

Question

在 SQL Server 2014 中，我每周对我的一个大表进行分区，并定义了一个滑动窗口方案，将最早一周的数据切换到存档数据库，并为下周创建一个新分区。

这是结果：

这是针对 AVL 系统（车辆跟踪）的。我在PositionDate ( datetime )上进行了分区。我们所有的查询在 WHERE 子句中都有PositionDate，在许多情况下，我们在 WHERE 子句中也有VehicleId。所以我在VehicleId ( int )上创建了两个对齐的索引：

• 一对(PositionDate,VehicleId) ;
• 一个就只是(VehicleId)。

但是在其 WHERE 子句中包含VehicleId 的每个查询中，这两个非聚集索引都没有使用（根据查询计划）。

我现在有一个性能问题。

我比较了分区表和非分区表之间的查询计划，如下所示：

Select * from MyNonPart_Table Where PositionDate between '2016-05-01' AND '2016-06-01'

Select * from PartitinedTable Where PositionDate between '2016-05-01' AND '2016-06-01'

令人惊讶的是，我看到第一个查询花费了 30%，但第二个查询花费了 70%。

我有一个文件组，其中包含两个用于分区表的文件。

我的问题：

1. 每个分区中的行数是否大于分区的最佳行数？如果我按天分区并保留最近 60 天的数据，这会帮助我提高性能吗？

2. 我的非聚集索引是否定义明确，或者我应该删除它们？我们在所有查询的 WHERE 子句中都有PositionDate，在其中许多查询中都有VehicleId。

3. 我是否在这种情况下滥用分区？如果我在非分区表上定义良好的索引并将最旧的数据（超过 2 个月）移动到存档表，这对我的情况是否有效？

我的索引的 DDL：

ALTER TABLE [dbo].[MyTable] ADD  CONSTRAINT [PK_Primary] PRIMARY KEY CLUSTERED 
(
    [PositionDate] ASC,
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

CREATE NONCLUSTERED INDEX [NonClusteredIndex-VehicleId] ON [dbo].[MyTable]
(
    [VehicleId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

CREATE NONCLUSTERED INDEX [NCIX_VehicleId_PositionDate] ON [dbo].[MyTable]
(
    [VehicleId] ASC,
    [PositionDate] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

这是一个示例，我的查询位于接收日期时间类型参数的SP 中。

Answer 1

您通常会错觉 - 与标准索引相比，分区将为您提供显着的查询性能提升。

不是这种情况。使用索引过滤和使用分区过滤之间几乎没有区别。

分区不是为了让您的查询更快，而是为了允许快速删除 - 通过换出一个带有空版本表的分区。这允许删除表格部分的“截断”样式性能 - 这很重要。非常重要的是，如果您经历过删除数十 GB 数据可能需要很长时间的经历。

也有分区可以提供帮助的插入场景。

但是对于查询 - 不，分区不会比适当的索引更好。事实上，它会更慢 - 因为那里的工作更复杂（管理要访问的分区）。

Answer 2

TomTom 有一个很好的答案，我完全同意。sp_BlitzErik 正确地引用了 Kendra Little 作为承认分区不是性能特征的好来源：

为什么表分区不能提高查询性能

分区实际上是一种数据管理功能。正如 TomTom 所指出的DELETE，包含分区内数据集的批量操作通过简单的元数据切换在几微秒内完成。此外，您可以对文件和文件组做一些事情，这将允许您将“较冷”的数据滚动到较慢的存储中，并为“热”数据释放较快的存储空间。

有些人误以为分区是一种性能特性，因为有时您可以进行分区消除，这将扫描的数据量减少到一个或几个分区。但是，条件需要恰到好处，并且您需要有一个受控的查询开发环境才能进行分区消除。

例如，我们的分区数据库很难在复杂查询和隐式转换中实现分区消除。最后，在不使用分区消除的分区表上，查询实际上可能比未分区的表慢，尤其是随着分区数量的增长。

分区不仅仅是在一张大桌子上折腾并希望它“更快”地工作。您需要考虑如何处理它的所有方面，从分区键到分区粒度，再到保留策略，再到存储策略。

最后，请不要只使用成本估算。使用SET STATISTICS TIME ON...运行查询，甚至SET STATISTICS IO ON可以真正了解它在做什么。