sql-server – SQL服务器如何计算出估计的行数?
我正在尝试调试一个相当复杂的存储过程,它连接多个tabls(10-11).我看到,对于树的一部分,估计的行数与实际行数大不相同 – 在最差的SQL服务器估计将返回1行,而实际上返回55,000行!
我想弄清楚为什么会这样 – 我的所有统计数据都是最新的,我已经在几个表上用FULLSCAN更新了统计数据.我没有使用任何用户定义的函数或表变量.据我所知,SQL服务器应该能够准确估计要返回的行数,但是它会继续选择一个计划,使其执行数万次RDI查找(当它只期望执行1次时)或2). 我该怎么做才能尝试理解为什么估计的行数超出了这么多? 更新:所以看一下这个计划,我发现了一个特别值得怀疑的节点 – 它使用以下预定表在表上扫描: status <> 5 AND [type] = 1 OR [type] = 2 这个谓词返回整个表(630行 – 表扫描本身它不是性能不佳的来源)但是SQL服务器的估计行数只有37个.然后SQL服务器继续用RDI做几个嵌套循环查找,索引扫描和索引搜索.这可能是我大量误算的根源吗?如何让它估计更合理的行数? 解决方法SQL Server使用以下数据将每个索引拆分为最多200个范围(从 here开始):
通常,大多数填充值都会进入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 优化器认为密钥2有3334行,索引访问太昂贵. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |