小编Jav*_*uzi的帖子

我在 DateTime 列上创建了分区表。过去 6 个月。我在名为“FG_OlderData”的文件组中放置了 3 个最旧的月份，在名为“FG_NewerData”的文件组中放置了 3 个最新的月份。分区函数定义：

CREATE PARTITION FUNCTION pf_Positions_LastSixMonth_MonthlyRange (DateTime)
AS RANGE RIGHT FOR VALUES (
                        -- older_than_current_minus_5
        '20150121', -- current_minus_5
        '20150220', -- current_minus_4
        '20150321', -- current_minus_3
        '20150421', -- current_minus_2
        '20150522', -- current_minus_1
        '20150622',  -- current
        '20150723'  -- Future
)
GO

分区架构定义：

CREATE PARTITION SCHEME ps_Positions_LastSixMonth_MontlyRange
AS PARTITION pf_Positions_LastSixMonth_MonthlyRange
TO (
      FG_OlderData,
      FG_OlderData,
      FG_OlderData,
      FG_OlderData,
      FG_NewerData, -- minus 2 month (to be moved to OlderData)
      FG_NewerData, -- minus 1 month
      FG_NewerData, -- current month
      FG_NewerData  -- …

在 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 …