5

我正在尝试调试一个相当复杂的存储过程，它连接了许多表（10-11）。我看到对于树的一部分，估计的行数与实际的行数有很大的不同——在最坏的情况下，SQL 服务器估计将返回 1 行，而实际上返回了 55,000 行！

我试图弄清楚为什么会这样 - 我的所有统计数据都是最新的，并且我已经在几个表上使用 FULLSCAN 更新了统计数据。我没有使用任何用户定义的函数或表变量。据我所见，SQL Server 应该能够准确估计将要返回多少行，但它会继续选择一个计划来执行数万次 RDI 查找（当它预计只执行 1或 2）。

我可以做些什么来尝试理解为什么估计的行数会减少这么多？

更新：所以查看计划，我发现了一个特别可疑的节点 - 它使用以下 predecate 对表进行表扫描：

status <> 5
AND [type] = 1
OR [type] = 2

此谓词返回整个表（630 行 - 表扫描本身不是性能不佳的根源）但是 SQL 服务器的估计行数仅为 37。然后 SQL 服务器继续在 RDI 上执行几个嵌套循环查找、索引扫描和索引查找。这会是我严重误判的根源吗？如何让它估计更合理的行数？

4

4 回答 4

8

SQL Server将每个索引拆分为200具有以下数据的范围（来自此处）：

  • RANGE_HI_KEY

    显示直方图步长上边界的键值。

  • RANGE_ROWS

    指定范围内的行数（它们小于 this RANGE_HI_KEY，但大于之前的 small RANGE_HI_KEY）。

  • EQ_ROWS

    指定有多少行完全等于RANGE_HI_KEY。

  • AVG_RANGE_ROWS

    范围内每个不同值的平均行数。

  • DISTINCT_RANGE_ROWS

    指定此范围内有多少个不同的键值（不包括之前的前一个键RANGE_HI_KEY及其RANGE_HI_KEY本身）；

通常，大多数填充值进入RANGE_HI_KEY.

但是，它们可以进入该范围，这可能导致分布偏斜。

想象一下这些数据（以及其他数据）：

键值行数

1          1
2          1
3          10000
4          1

SQL Server通常建立两个范围：1到3和4到下一个填充值，这使得这些统计信息：

RANGE_HI_KEY  RANGE_ROWS  EQ_ROWS  AVG_RANGE_ROWS  DISTINCT_RANGE_ROWS
3             2           10000    1               2

，这意味着在搜索时，比如说，2只有1一行，最好使用索引访问。

但如果3在范围内，统计数据如下：

RANGE_HI_KEY  RANGE_ROWS  EQ_ROWS  AVG_RANGE_ROWS  DISTINCT_RANGE_ROWS
4             10002       1        3334            3

优化器认为3334键2和索引访问成本太高。

于 2009-09-25T11:21:33.343 回答
3

它使用为每个索引保留的统计信息。

（您还可以在非索引列上创建统计信息）

要更新数据库中每个表的所有统计信息（警告：在非常大的数据库上需要一些时间。不要在没有与 DBA 核对的情况下在生产服务器上执行此操作......）：

exec sp_msforeachtable 'UPDATE STATISTICS ?'

如果您没有定期计划的作业来重建最活跃的索引（即大量 INSERTS 或 DELETES），则应考虑重建索引（与上述相同的警告适用）：

exec sp_msforeachtable "DBCC DBREINDEX('?')"
于 2009-09-25T11:17:39.030 回答
0

由于您已经更新了统计信息，我会尝试消除任何参数嗅探：

CREATE PROCEDURE xyz
(
    @param1 int
    ,@param2 varchar(10)

)AS

DECLARE @param_1 int
       ,@param_2 varchar(10)

SELECT @param_1=@param1
      ,@param_2=@param2

...complex query here....
...WHERE column1=@param_1 AND column2=@param_2....

go
于 2009-09-25T11:17:29.497 回答
0

重建索引可能会解决不正确的估计行值问题

于 2010-08-04T18:57:25.920 回答