SQL Server 是否会像本文建议的那样忽略 varchar 列的统计信息？

Question

_{（我不认为这个问题是8 年前这个问题的重复，因为我不是问超大列的优点，我问的是下面链接文章中展示的行为。）}

从SQLPerformance.com这最近（2017年）的文章演示了如何改变最大长度n为一varchar(n)列影响查询计划行大小估计和排序缓冲区的大小估计会导致欠佳的性能和内存分配警告。

在其中，作者声称（强调我的）：

从这里我们看到，列定义越大，估计的行和数据大小就越大。在这个简单的查询中，无论定义如何，所有查询的 I/O 成本 (0.0512731) 都是相同的，因为聚集索引扫描无论如何都必须读取所有数据。

但在其他情况下，此估计行和总数据大小会产生影响：需要额外资源的操作，例如排序。

当我读到那个声明（以粗体显示）时，我感到很惊讶，因为我认为 SQL Server 会从STATISTICS在这些相同表上维护的采样对象中获得相当准确的行大小估计。特别是考虑到SELECT AVG(LEN(email))文章中的查询显示没有列的值超过 77 个字符。

这篇文章还明确地执行了一个ALTER INDEX ALL ON dbo.Table REBUILD-这个 DB.SE 帖子说它也将自动更新STATISTICS。

（虽然我很惊讶 SQLPerformance 文章中根本没有出现“统计”这个词——所以也许在作者的情况下，由于某些机器配置，统计数据根本没有更新，他们没有注意到？）

SQL Server 是否仅对varchar行大小估计使用列长度​​限制？如果不是，那么为什么 SQLPerformance 文章描述相同？

Answer 1

SQL Server 是否仅对行大小估计使用 varchar 列长度限制？如果不是，那么为什么 SQLPerformance 文章描述相同？

正确的。SQL Server 在估计行大小时仅使用 varchar（最大指定）长度。SQLPerformance 文章准确地描述了估计的行大小度量。

更长的答案

在链接文章中的示例中，Aaron 重建了所有索引以确保查询的所有版本在索引大小和统计信息方面都具有平等的竞争环境，以便所有情况的执行计划都是“理想的”并且（如实验证明的那样） )几乎相等，但不完全相等。

统计信息用于估计将返回多少行，而不是为执行查询授予多少内存。

在文章中，Aaron 说（强调我的）：

SQL Server 必须考虑列中可能包含多少数据。它不是基于对数据的实际分析来做到这一点的，也不能基于 <= 201 histogram step values 做出任何假设。相反，它必须估计每一行都包含声明列大小的一半的值。因此，对于 varchar(4000)，它假定每个电子邮件地址的长度为 2,000 个字符。

Aaron 对“直方图步长值”的引用是对统计直方图的引用。统计直方图包含表中最多 201 个数据值的知识。它知道那些（最多 201 个）显式值的实际长度，但它不知道这些值之间的值。

此外，统计基于数据样本，因此可能存在未作为样本的一部分进行分析的行，并且依赖统计数据的最小/最大/平均长度将是过时或不具有代表性的样本不利的另一个机会影响查询执行。