解释SQL Server表统计信息

Question

我写的查询和程序，我没有作为一个数据库管理员的经验，我不在这样的位置。我使用的是数百个表，而某些较旧的表很难使用。我怀疑统计数据是一个问题，但DBA声明情况并非如此。

我不知道如何解释统计数据，甚至不知道我应该看哪些统计数据。举个例子，我目前使用的是JOINing 2表，这是一个使用索引的简单连接。

它在4列中返回不到500行。它的运行速度非常快，但在每天运行数千次的生产环境中就不是这样了。我对这个连接的估计行数和实际行数相差了462%。

我已经将这个存储过程提炼成许多非常基本的临时表，以定位问题区域，它看起来是两个表，这个例子就是其中之一。

​

​

我想知道的是要运行哪些命令，以及要查看哪些统计数据，以便DBA讨论手头的具体问题。我不想成为对抗性的而是信息性的。我与这位数据库管理员有非常好的专业关系，但他的政策是非常非黑即白的，所以我可能最终不会取得任何进展，但如果我遇到障碍，我也可以发挥领导作用。

我对表的索引运行了一个DBCC SHOW_STATISTICS。我不确定这是我需要的数据，还是我真正在看的数据。我真的很想知道从哪里开始。我已经用谷歌搜索过了，但我读到的所有页面都非常适合DBA，并且假设我没有的领域的先验知识。

​

​

下面是我的连接的一个模糊示例-我的连接在一个临时表上索引需要的前两个条件，日期条件在删除时会使连接变得更糟，读取次数为10倍：

SELECT
    x.UniqueID,
    x.ChargeCode,
    x.dtDate,
    x.uniqueForeignID
INTO
    #AnotherTempTable
FROM
    Billing.dbo.Charges x
JOIN 
    #temptable y ON x.uniqueForeignID = y.uniqueID
                 AND x.ChargeCode = y.ChargeCode
                 AND @PostMonthStart <= x.dtDate 
                 AND x.dtDate < @PostMonthEnd

上面的连接是一个新计划的一部分，在这个计划中，我一直在将所有需要的数据分解到临时表中，以确定高CPU和生产中读取问题的根本原因。下面是正在执行的所有语句的列表，按读取次数排序。第二行是这个示例查询，但还有其他具有类似问题的查询。

​

​

下面是我更新之前计划的执行计划操作。

​

​

虽然新计划有更好的运行时间和更接近的估计，但我担心如果统计数据关闭，我仍然会遇到问题。如果我完全错了，请告诉我并给我指出正确的方向，如果我做了错误的假设，我会很高兴地换一棵树。

Answer 1

返回的第一个表显示了一些一般信息。您可以查看此指数的统计数据，上次更新时间为2019年12月25日晚上10:19在写这个答案的时候，也就是昨天晚上，所以最近更新了统计数据。这可能是某种夜间维护，但也可能是触发自动统计更新的数据修改阈值。

在对统计数据进行采样时，表中有222,596,063行。统计数据更新对其中626,452行进行了采样，因此采样率为0.2%。此采样大小可能是简单update statistics MyTable命令使用的默认采样速率。

0.2%的采样率计算起来很快，但可能会导致非常糟糕的估计--特别是在索引用于支持外键的情况下。例如，父/子关系可能在子表上有一个ParentKey列。低统计采样率将导致每个父行的估计值非常高，这可能导致查询计划中出现奇怪的决定。

请看第三个表(直方图)。RANGE_HI_KEY对应于此索引中第一列的特定键值。EQ_ROWS列是直方图对与该键对应的行数的估计。如果您通过RANGE_HI_KEY列中的这些键之一获得该表中的行数，那么EQ_ROWS列中的数字看起来像是一个准确的估计值吗？如果不是，较高的采样率可能会产生更好的查询计划。

例如，取值1475616。这个键的行数是否接近3893的EQ_ROWS值？

select count(*) from MyTable where FirstIndexColumn = 1475616

如果估计值非常差，DBA可能需要增加此表上的样本大小：

update statistics MyTable with sample 5 percent

如果数据库管理员使用Ola Hallengren's plan (在我看来，这是一个很好的选择)，可以通过将@StatisticsSample参数传递给IndexOptimize过程来实现。