大表上的多列统计数据产生较差的估计

Question

我有一个相当大的表（约 2 亿行），虽然统计数据是最新的WITH FULLSCAN，但我的直方图（限制为 200 步）是否可能过于宽泛，优化器无法做出正确的估计 - 换句话说，是不是已经不够“选择性”了？使用这个特定客户的数据库/表，我的查询计划估计与其他人相比相差甚远。

我关注的特定统计数据来自表的 PK/CLUSTERED INDEX。它是一个包含int( ParentId) 和smalldatetime( TimeStamp)的多列统计信息。

当我发出 a 时DBCC SHOW_STATISTICS('SomeTable', 'PK_SomeTable')，我得到以下输出（省略了直方图 - 但如果有帮助，我可以发布它）：

Name                    Updated              Rows       Rows Sampled    Steps   Density         Average key length  String Index    Filter Expression   Unfiltered Rows
PK_SomeTable            Jan 31 2014 10:59AM  181170887  181170887       200     2.022617E-05    8                   NO              NULL                181170887

All density     Average Length  Columns
0.0004892368    4               ParentId
5.519651E-09    8               ParentId, TimeStamp

我的大部分查询都是使用这两个列 (ParentId和TimeStamp)的组合来执行的。小的 all 密度值显示了这对的选择性 - 显然，因为它是 PK。

(1) 直方图似乎只显示ParentId列。我在这里错过了什么吗？是否考虑了两列？

(2) 如果我采用 200,000,000 行 / 200 步，我基本上在每个直方图步骤中定义了 1,000,000 行。这似乎足够大，可能会导致估计问题，对吗？排序溢出到 tempdb 之类的东西呢？

(3) 手动创建的统计数据/过滤的统计数据是一种探索途径吗？如何决定应用哪种类型的过滤器？

Answer 1

对于这么大的表，我会考虑分区。不幸的是，我无法回答您的具体问题 (1-3)，但总的来说，使用分区视图（而不是本机分区）的好处之一是分区视图中的各个表被视为单独的对象，并且每个表都有自己的统计信息200 步。 这是 SQLSkills 的 Kimberly Tripp 为大型表推荐的帖子，您不仅要考虑分区或分区视图，还要考虑将两者结合起来。

如果您不知道分区视图是这样一种视图，其中您有多个表，每个表保存一部分数据，顶部的视图与 UNION ALL 将表组合在一起。

如果您有兴趣，这里是 Kimberly 的另一个关于统计的博客。 它应该可以帮助您回答一些其他问题。

这是康纳·坎宁安 (Connor Cunningham) 的一篇关于统计的文章：统计、该死的谎言和统计 – 什么是 Statman？