统计和行估计

Question

希望有人可以帮助我了解 SQL Server 如何使用 stats 来估计记录数。

测试脚本

USE [tempdb]

GO

CREATE TABLE t1
(
a INT NOT NULL, 
b INT NOT NULL, 
c INT CHECK (c between 1 and 50), 
CONSTRAINT pk_a primary key(a)
);

GO

INSERT INTO t1(a,b,c) 
SELECT number, number%1000+1, number%50+1 
FROM master..spt_values 
WHERE type = 'P' AND number BETWEEN 1 and 1000;

GO

CREATE STATISTICS s_b ON t1(b);
CREATE STATISTICS s_c ON t1(c);

GO

示例查询

DECLARE @c INT=300 
SELECT * FROM t1 WHERE b>@c 
SELECT * FROM t1 WHERE b>300

查询 1

估计行数 300

查询 2

估计行数 700

问题

1. 为什么第 1 次和第 2 次查询行估计之间存在如此巨大的差异。
2. 第二个查询 SQL 如何从 Stats 估计到 700
3. 任何学习这些的好文章。

Answer 1

查询给出不同的估计，因为第一个没有从Parameter Embedding Optimization 中受益。从优化器的角度来看，查询也可能是：

SELECT * FROM t1 WHERE b>???; 

为了了解基数估计如何适用于简单查询，有时我会考虑如果我必须对查询优化器进行编程以生成估计值，我会怎么做。通常，这些想法与 SQL Server 所做的并不完全匹配，但我发现记住优化器几乎总是处理不完美或有限的信息会很有帮助。让我们回到你的第一个查询：

DECLARE @c INT=300; 
SELECT * FROM t1 WHERE b>@c; 

没有RECOMPILE提示，优化器不知道@c局部变量的值。这里没有足够的信息来进行适当的估计，但优化器需要为所有查询创建一个估计。那么优化器的程序员能做什么呢？我认为可以实现基于列中值的分布进行猜测的复杂算法，但 Microsoft 对未知的不等式使用 30% 的硬编码猜测。您可以通过更改局部变量的值来观察这一点：

DECLARE @c INT=999999999; 
SELECT * FROM t1 WHERE b>@c; 

估计仍然是 300 行。请注意，估计不需要在查询之间保持一致。以下查询也估计有 300 行，而不是 1000 - 300 = 700：

DECLARE @c INT=300; 
SELECT * FROM t1 WHERE NOT (b>@c); 

从概念上讲，它可以重写为

DECLARE @c INT=300; 
SELECT * FROM t1 WHERE b<=@c; 

这将具有相同的硬编码 30% 估计。

您的第二个查询不使用局部变量，因此优化器可以直接使用您在列上创建的统计对象来帮助估计。直方图最多只能有 201 个步骤，并且您的表有 1000 个不同的值，因此有些过滤器值中优化器没有完整的信息。在这些情况下，它需要做出更多的猜测。以下是查看b列直方图的方法：

DBCC SHOW_STATISTICS ('t1', 's_b') WITH HISTOGRAM;

在我的机器上，我很幸运，300 是直方图步骤之一的高值：

您可以在文档中找到对不同列的解释。展望未来，我将假设您知道它们的含义。查询请求带有 的行b > 300，因此 aRANGE_HI_KEY为 300的直方图无关紧要，所有具有较低 的步骤也是如此RANGE_HI_KEY。对于这个查询，我会对优化器进行编程，以简单地将直方图剩余 133 个步骤的所有RANGE_ROWS和EQ_ROWS值相加。这些列加起来为 700，这是 SQL Server 的估计值。

其他过滤器值可能无法给出准确结果。例如，以下两个查询都有 704 行的基数估计：

SELECT * FROM t1 WHERE b>293; -- returns 707 rows
SELECT * FROM t1 WHERE b>299; -- returns 701 rows

两个估计都非常接近，但并不完全正确。直方图不包含这些值的足够信息，无法提供准确的估计。