问题标签 [partitioned-view]

我有一个相当大的表，我需要查询它以获取报告应用程序。大多数情况下，用户会对最近 7 天的数据感兴趣，但他们希望能够时不时地查询旧的（存档数据）。由于他们希望最近数据的一切都快得惊人，但不介意等待存档记录，我猜我应该对分区视图 ( data) 和两个表 (data_current和data_archive) 没问题。

我知道如何创建初始表（约束和所有）和视图。如何实现日常维护自动化（将旧数据从_current移至_archive）？

我试图让分区视图工作，但仍然看到查询优化器扫描两个表。这是我的脚本：

但是当我查看执行计划时，我看到表A和表B都被扫描了，并且两个表的“执行次数”都是 1。我希望表A有Number of Executions = 1，表B有Number of Executions = 0。我在SQL Server 2012。

有人可以澄清这应该如何工作吗？谢谢你。

以下是设置和测试脚本。测试脚本假设只扫描表 T4。但是，当 T1 和 T4 的行数超过 10000 时，它会开始扫描这两个表。

测试代码：

执行错误（测试 T1 有 100 行，T4 有 10000 行）：

好（当两个表只有 100 行时测试）：

xml中的良好执行计划：

https://docs.google.com/file/d/0B6OXmuJYfpRcTE9Pd0xpSEhEQy04eWZqa2lKejM5YkdPRHFr/edit?usp=docslist_api

xml 中的错误执行计划： https ://docs.google.com/file/d/0B6OXmuJYfpRcU2ZUVFdtLUcxQk83TVFSNUFoZEYtbVdaWU4w/edit?usp=docslist_api

背景

我正在将应用程序从包含 0.5-13 亿条记录的单个事件表的模式迁移到具有 30-180 个相同基础表的分区视图，每个基础表都包含该记录数的一小部分，这大大缓解了围绕管理和查询那么多记录。我使用分区视图而不是表分区，因为并非所有用户都可以访问 SQL Server 2012 的Awesome Edition。

分区函数基于事件当天的笛卡尔积和事件的一个属性。换句话说，2015 年 6 月 1 日的所有事件都进入了类似“Event20150601_foo”的表中，所有具有属性“bar”的事件进入了“Event20150601_bar”，并且对于接下来的一天，事件将进入“Event20150602_foo”和“Event20150602_bar”等。通常有 2-3 个属性值和 15-60 天的事件，映射到 30-180 个不同表的典型范围。

每个表的基本结构是由 EventId (bigint) 和 PartitionKey (int) 组成的复合聚集主键，后跟一些其他未索引的列。EventId 是唯一的，在所有表中单调递增，并按顺序实现。PartitionKey 对于每个分区表都是唯一的，因此每个表的检查约束只是“CHECK (PartitionKey = x)”，其中 x 是每个分区表定义的。即使我无法提供分区键来缩小搜索范围，这也允许我通过聚集索引搜索来搜索 EventId。在我可以同时提供 EventId 和 PartitionKey 的情况下，查询非常有效，因为优化器可以只在与分区键匹配的单个表上执行索引查找，这是一个很大的性能提升。

实验

如果我可以根据事件发生的日期和更广泛的属性组合（500-5000 而不是前面提到的 2-3）进行更细化和分区，这将使我的生活更加轻松，这将需要我在范围为 10,000-50,000 个不同的分区。我在一个包含 20,000 个不同表的数据库上对此进行了测试，不幸的是，我发现不同操作的运行时间随着表数量的增加而以高于线性的速度增长。根据查询统计，大部分时间都花在了解析和编译查询上，而不是执行查询上。

以下是我发现的不同操作的运行时间（请原谅基本表）：

• 创建分区视图
  • 100 tables : 50ms
  • 1000 tables : 800ms
  • 2000 tables : 2,660ms
  • 4000 tables : 10,000ms
  • 16000 tables: 225,000ms
• select * from PartitionedView where EventId = x（扫描所有表）
  • 100 tables : 78ms parse/compile time; 25ms exec time
  • 1000 tables : 3,500ms parse/compile time; 160ms exec time
  • 2000 tables : 15,000ms parse/compile time; 500ms exec time
  • 4000 tables : 68,000ms parse/compile time; 2,000ms exec time
  • 16000 tables:解析/编译时间超过 10 分钟后取消！
• select * from PartitionedView where (EventId = x) and (PartitionKey = y)（只扫描一张表）
  • 100 tables : 74ms parse/compile time; 1ms exec time
  • 1000 tables : 2,500ms parse/compile time; 15ms exec time
  • 2000 tables : 11,000ms parse/compile time; 10ms exec time
  • 4000 tables : 50,000ms parse/compile time; 16ms exec time
  • 16000 tables:解析/编译时间超过 10 分钟后取消！

问题

我应该因为考虑使用那么多桌子而被责骂吗？如果没有，当存在大量表时，有没有办法可以减少查询解析和编译时间？

我正在尝试创建一个分区视图，但是我的执行计划显示它仍在访问两个基础表。

SQL小提琴在这里

为什么我的查询仍然访问两个基础表，然后将它们连接起来？

如何在 SQL Server（标准版）上对两个具有外键的表（父表和子表各 1TB）进行分区视图，而不更改从应用程序调用的查询，从而使查询效率不低？

这是架构（简化）：（或在SQL Fiddle上）

以下是可能性：

a) 如果我根据 DateProduced 对表 Product 进行分区视图（分区将按月计算），我无法有效地按表的主键SELECT * FROM Product WHERE idProduct=3搜索（将在表 Product 的所有分区中搜索）。

b) 如果我根据 idProduct 对表 Product 进行分区视图，我无法有效地按 DateProduced 搜索。

我也有问题如何使两个表都分区。

是否有可能以某种方式对两个表进行合理的分区视图，而查询没有大的变化（搜索日期之间的所有产品，通过 productId 获取产品），这样它就不会太慢？

我有下一个分区视图：vwSalesOutH。它由不同数据库中名为“SalesOutH”的多个表组成。

当我使用下一个查询时，它工作正常，搜索是通过一个表 vwSalesOutH：

统计 IO：

当我使用下一个查询时，在“where”块中使用相同的日期时，我遇到了问题 - 搜索是按分区视图中的所有表进行的：

统计 IO：

你能给我建议来解决第二个查询吗？

我们目前有一些客户，他们的查询需要很长时间才能从分区视图中获得结果。经过仔细检查，我们发现了扫描每个表的执行计划，而不仅仅是那些具有相关数据的表。

为了隔离这种行为，我从https://technet.microsoft.com/en-us/library/ms190019(v=sql.105).aspx获取了分区视图示例并重新创建了我们的问题：

在此示例中，我们有 12 个表（针对 1998 年的每个月）：

我们正在查看如下视图：

现在我们有了一个运行良好的查询（只扫描必要的表）：

但是如果我们用参数过滤，它会突然扫描所有表：

我解释这种行为的第一个猜测是 Microsoft SQL Server 会构建一个执行计划，它会扫描所有表，并在每次执行此查询时重用它，因此始终扫描所有表。

有谁知道我们如何让 SQL Server 只扫描必要的表并仍然使用参数化过滤器？或者任何人都可以确认这是 SQL Server 执行计划生成器中的错误吗？

有关完整代码，请查看此 SQL Fiddle： http ://sqlfiddle.com/#!6/e1f33/1

我设置的分区视图有一个奇怪的问题。

例如，假设我有一个 Orders & Orders_Archive 表，可以通过分区视图访问。每个订单都有一个 OrderType，可以通过外键访问并存储在查找表中。

订单有一个字段来表示它是否处于活动状态或已归档： [ArchiveYearMonth] char(5)。（我意识到将日期存储在字符串中并不是最佳选择，但为了示例而忽略它）。

这三个表的架构如下所示：

我已经设置了这样的视图：

直接查询时按预期工作：

实际执行计划导致仅扫描 Orders 和 OrderTypes：

表“订单类型”。扫描计数 1，逻辑读取 52，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。
表“订单”。扫描计数 1，逻辑读取 102，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

但是，当我针对另一个表加入分区视图时，我在执行计划中遇到了一些意外行为。

设置一个小表，其中包含来自 Orders 和 Order_Archive 表的一些记录：

现在将原始视图与临时表连接起来：

结果还可以，只查询了Orders表，但是执行计划很糟糕。Orders 和 OrderTypes 表都被扫描、连接，然后与临时表连接。（Orders 表有 20,000 条记录；临时表有 20 条）。

针对 AllOrders_ProperFilter 的执行计划

现在，如果我从视图中删除分区并对其进行查询，我会得到不同的结果：

执行计划现在扫描临时表，使用 PK 查找 Orders 表，然后针对 OrderTypes 进行联接。预计，它还查询 Orders_Archive 表，因为约束已被删除。

针对 AllOrders 的执行计划

为什么当另一个表连接到视图时，具有两个约束 ([AllOrders_ProperFilter]) 的视图性能如此差？

注意 - 当我对表添加实际约束时，我得到了相同的结果：

显然我不能发布两个以上的链接，但我有一个示例脚本，它使用虚拟数据重新创建问题。

我正在尝试一次加载多个文件。它们都是分区文件当我尝试使用 1 个文件时它可以工作，但是当我列出 24 个文件时，它给了我这个错误，除了在加载后执行联合之外，我找不到任何关于限制的文档和解决方法。有其他选择吗？

下面的代码重新创建问题：

收到错误：