根据MS,AVG_RANGE_ROWS
的描述如下:
直方图步骤中列值重复的平均行数,不包括上界。当DISTINCT_RANGE_ROWS大于0时,用RANGE_ROWS除以DISTINCT_RANGE_ROWS计算AVG_RANGE_ROWS。当DISTINCT_RANGE_ROWS为0时,AVG_RANGE_ROWS返回1作为直方图步骤。
我在看最后一行,如果确实是这样的话,我很想知道为什么在直方图步骤中看到AVG_RANGE_ROWS
的值不等于1
( DISTINCT_RANGE_ROWS
是0
)。
所讨论的统计数据是在打开自动创建统计信息选项时由Server创建的列stat。我使用的是数据库的旧版本,但使用的是最新的补丁-- Server 2014 SP3,CU4+GDR (12.0.6372.1)。
有点不幸的是,由于一个次优的查询计划,我们上周几乎崩溃了。最终的结果是大量的扫描和膨胀的内存授权。用更高的百分比重新采样统计数据暂时解决了这个问题,但我最想知道的是,在初始语句或已知问题周围是否存在异常(可能使用跟踪标志来解决?)在我们无法控制采样大小的情况下,如何防止自动创建的统计数据再次发生这种情况?
发布于 2020-09-28 06:41:34
正如在对格式不良的直方图会导致嵌套循环上的错误估计。的答复中所描述的,抽样统计数据的计算和存储方式发生了变化,特别是在应用缩放时。
作为一个副作用,DISTINCT_RANGE_ROWS
的值在0到1之间(980.235 / 386212.6 = 0.002538071)。该列具有公开的bigint
类型,因此它被舍入为零。
显然,当范围包含非零行数时,不可能真正有零个不同的值。
人们只能希望在某个阶段消除这些差异;尽管很难想象如果不改变数据类型(扩展到sys.dm_db_stats_histogram
(可在Server 2016及更高版本上使用)),这种情况会是什么样子。
至于你做了什么,如果你确信这不仅仅是一个显示问题,而且实际上导致了很差的估计,你应该把它报告为一个回归。
发布于 2023-05-31 09:44:30
我认为,造成抽样统计数据不佳的根本原因可能实际上是统计引擎本身的一个缺陷。我在这里添加了我自己的帖子,试图描述我认为我发现了什么-- 抽样统计生成中可能缺少的步骤?。从本质上说,DISTINCT_RANGE_ROWS仅仅代表了样本的大小--不管是1%还是100% --导致AVG_RANGE_ROWS向相反的方向外推得太远,无法进行补偿。我们可以提前将现有的统计数据转换为全扫描,但这并不能真正帮助我们快速创建统计数据.
编辑-我是说.如果我们处于全扫描模式,我们总是有非零DISTINCT_RANGE_ROWS,其中AVG_RANGE_ROWS > 1,对吗?我认为样本总是不太准确,即使它们不应该像现在那样不准确,所以即使采样比现在更准确,我想我们仍然有像上面这样的直方图的可能性。
https://dba.stackexchange.com/questions/276168
复制相似问题