SQL 服务器在哪里获取 AUTO_CREATE_STATISTICS 关闭时的估计行数

Question

当您关闭AUTO_CREATE_STATISTICS时，SQL 服务器从哪里获得估计的行数？

这是一个例子：

设置实验：

USE master;
GO

IF EXISTS(SELECT * FROM sys.databases WHERE name = 'TestDatabase')
BEGIN
    ALTER DATABASE TestDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE TestDatabase;
END

GO

CREATE DATABASE TestDatabase;

GO

ALTER DATABASE TestDatabase SET AUTO_CREATE_STATISTICS OFF;

GO

USE TestDatabase;

GO

DROP TABLE IF EXISTS TestTable;

GO

CREATE TABLE TestTable
(
    Id INT NOT NULL IDENTITY PRIMARY KEY,
    FirstName VARCHAR(50),
    LastName VARCHAR(50)
);

请查看更新代码的编辑

实验：

插入 200 行：

SET NOCOUNT ON;
INSERT INTO TestTable Values('Test', 'Blah')
GO 200

突出显示以下查询时单击Display Estimated Execution Plan ：

SELECT * 
FROM TestTable 
WHERE LastName = 'blah';

它给了我估计的 # 行 200。

再次运行以下查询：

SET NOCOUNT ON;
INSERT INTO TestTable Values('Test', 'Blah')
GO 200

在突出显示下面的查询时再次单击Display Estimated Execution Plan ：

SELECT * 
FROM TestTable 
WHERE LastName = 'blah';

它给了我估计的 # 行 400。

现在我运行查询而不是获取估计值

SELECT * 
FROM TestTable 
WHERE LastName = 'blah';

现在我再插入 200 行

SET NOCOUNT ON;
INSERT INTO TestTable Values('Test', 'Blah')
GO 200

在突出显示下面的查询时再次单击Display Estimated Execution Plan ：

SELECT * 
FROM TestTable 
WHERE LastName = 'blah';

它再次给了我估计的 # 行 400 而不是 600 行。

所以我跑

SET NOCOUNT ON;
INSERT INTO TestTable Values('Test', 'Blah')
GO 10000

在突出显示下面的查询时再次单击Display Estimated Execution Plan ：

SELECT * 
FROM TestTable 
WHERE LastName = 'blah';

为 man 提供 400 行而不是 10,600 行的估计计划。

因此，如果您在运行查询之前获得估计的行数，它就会为您提供表中的总行数。 运行查询后，它会在运行查询之前为您提供表中的总行数。

那么 SQL 服务器究竟是从哪里得到这个数字的呢？

---编辑 1：我的结果错了，很抱歉造成混淆---

当我昨天得到上述估计时，我将我的实验更改为AUTO_CREATE_STATISTICS ON以测试该行为并且没有意识到它仍然存在。 抱歉造成混乱。

所以让我展示一下AUTO_CREATE_STATISTICS OFF的截图：

• 我从一个新数据库和一个AUTO_CREATE_STATISTICS OFF的新表开始。
• 我插入 200 行
• 突出显示以下查询时单击Display Estimated Execution Plan ：

SELECT * 
FROM TestTable 
WHERE LastName = 'blah';

• 估计是
  • Estimated Number of Rows to be Read为 200 行
  • Estimated Number of Rows for All Executions为 14.142（即 200.000^.50）。
• 我再插入 200 行
• 上面的查询再次点击Display Estimated Execution Plan
• 估计是
  • Estimated Number of Rows to be Read为 400 行
  • Estimated Number of Rows for All Executions为 20（即 400.000^.50）。
• 现在我运行上面的查询并按预期获得 400 行。
• 我插入 200 行
• 上面的查询再次点击Display Estimated Execution Plan
• 估计是
  • Estimated Number of Rows to be Read为 400 行
  • Estimated Number of Rows for All Executions为 20（即 400.000^.50）。
• 我插入 10000 行
• 估计是
  • Estimated Number of Rows to be Read为 400 行
  • Estimated Number of Rows for All Executions为 20（即 400.000^.50）。
• 做一个统计更新：

UPDATE STATISTICS TestTable;

• 即使在统计数据更新后，估计也是一样的
  • Estimated Number of Rows to be Read为 400 行
  • Estimated Number of Rows for All Executions为 20（即 400.000^.50）。

因此，一旦您运行查询，即使在进行统计更新后，用于计算估计值的行也会被锁定。 这看起来真的很糟糕。

• 问题是，为什么它在您运行查询后使用锁定的行而不是使用表中的当前行数？
• 此行数是否存储在 DMV 中以供查看？

---编辑1结束---

Answer 1

当 AUTO CREATE STATISTICS 被禁用时，SQL 服务器使用“基数估计器”来估计查询将返回的行数。

基数估计器根据许多因素进行此估计，包括表中列的数据类型和分布、查询中使用的特定谓词以及任何可用的统计信息。

在您的示例中，估计器似乎正在估计表中的总行数，而不是查询中的特定谓词（“LastName = 'blah'”）。

这很可能是由于表缺少统计信息，而统计信息通常用于更准确地估计行数。

Answer 2

我强烈建议永远不要将AUTO_CREATE_STATISTICS设置为OFF所以希望这个问题只是出于学术兴趣。

SQL 服务器知道表基数（表中的行数），因为它保存在独立于统计信息的表元数据中。 当您说“估计有 200 行”等时，您指的是“估计要读取的行数”吗？

由于LastName上没有索引，它必须扫描整个表以找到与WHERE子句匹配的行，这将与表基数相同。 没有基数估计器 model 会假设这些行中的 100% 将匹配LastName = 'blah' 。 对于表中的 200 行，我使用 QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110 和 14 ( SQRT(200) ) 获得了 53 的估计值以及所有后来的。

无论哪种方式，这都只是基于将匹配的猜测比例，因为（在没有任何列统计信息或约束的情况下）没有其他任何东西可以用来作为这个数字的基础。

当您生成估计的执行计划时，它不会存储在计划缓存中。 当您实际运行它时，计划会被缓存。 所以这就是为什么当您到目前为止所做的只是生成估计计划时，您会看到“读取的行数”估计与实际表基数一致。

它给了我估计的 # 行 400。

现在我运行查询而不是获取估计值

您在表有 400 行时执行了查询，这将执行计划添加到缓存中（完成 400 行估计）——因此未来的执行可以使用这个缓存的计划。

一旦计划在缓存中，您将依赖于修改的行数是否触发基于最优性的重新编译并且您获得新的执行计划，或者它是否低于仅使用缓存计划的阈值。

通常向一个 400 行的表中添加 10,200 行将远远超过跨越“重新编译阈值”并触发基于优化的编译所需的内容。 我认为在这种情况下不会发生这种情况，因为计划中从未使用过任何统计数据，因此它永远不会将这些统计数据视为过时的。