分区表和索引 - 有什么缺点？

Question

当谈论分区表和索引少于 100 个分区的表时，

没有未对齐的索引：

我的意思是：

非对齐索引

一个独立于其对应表分区的索引。

也就是说，索引具有不同的分区方案或放置在与基表不同的文件组中。

设计非对齐分区索引在以下情况下很有用：

基表尚未分区。

索引键是唯一的，不包含表的分区列。

您希望基表参与使用不同连接列的更多表的并置连接

是否还有其他性能缺陷：

1 - 减慢一些 DBCC 命令

2 - 在分区列以外的列上使用诸如 TOP 或 MAX/MIN 等运算符的查询可能会遇到分区性能降低的情况，因为必须评估所有分区。

3 -

使用分区消除的查询可能具有与大量分区相当或改进的性能。随着分区数量的增加，不使用分区消除的查询可能需要更长的时间来执行。

Answer 1

扩展您的列表，以下是我们在实际生产工作负载中遇到的几个潜在缺点：

寻找多个分区

扩展不使用分区消除的查询可能需要更长的时间来执行点，有一个特定的模式特别受到影响：单例搜索。如果需要访问所有（甚至是适度的）分区子集，此操作将变得更慢。在跳跃扫描操作基本上执行寻道到每一个不能被消除分区。

假设您有 10 亿行表 ( N = 1,000,000,000)，其中的行均分为 1,000 个分区 ( P = 1,000)。单个查找大致O(log(N)) ~ 30在未分区的表中。然而，这个相同的查找操作O(P*log(N/P)) ~ 20,000在这个假设的分区表中变得粗略。因此，如果需要来自所有分区的数据（或者有时即使不需要，但 SQL 无法根据您的查询证明这一点），则搜索现在执行的工作量会增加 500 倍以上。

请注意，当您显式查询表中的一行（或一小部分行）时，以及当分区表出现在循环连接的内侧时，在更复杂的查询中都会出现这种情况。好消息是 SQL Server 在基于成本的优化中考虑到这一点是相当不错的，但这通常仍然意味着当循环查找到非分区表时，您会得到一个散列连接。

并行查询执行中的线程倾斜

在并行查询计划中，线程被分配给分区。如果有一个分区比其他分区大得多，则对表的查询可能特别容易受到线程倾斜的影响。一个线程可能获得的行比例太高，并且在其他线程完成工作后很长时间才进行处理。这种情况也可能发生在非分区表上，但任何不平均分配行的分区函数都特别容易受到攻击。

有关将线程分配到分区的更详细说明，请参阅分区对象的并行查询执行策略。例如：

查询处理器对从分区对象中选择的查询使用并行执行策略。作为执行策略的一部分，查询处理器确定查询所需的表分区以及分配给每个分区的线程比例。在大多数情况下，查询处理器为每个分区分配相等或几乎相等数量的线程，然后跨分区并行执行查询。