sql-server – 为什么这个毗连基数预计云云之大？

原始查询中的派生表已被删除,而且投影已尺度化.执行初始基数和选择性预计的树的SQL暗示情势为：

SELECT 
    PRIMARY_ID = COALESCE(d1.JOIN_ID,d3.JOIN_ID)
FROM X_DRIVING_TABLE dt
LEFT OUTER JOIN X_DETAIL_1 d1
    ON dt.ID = d1.ID
LEFT OUTER JOIN X_DETAIL_LINK lnk 
    ON d1.LINK_ID = lnk.LINK_ID
LEFT OUTER JOIN X_DETAIL_2 d2 
    ON dt.ID = d2.ID
LEFT OUTER JOIN X_DETAIL_3 d3 
    ON dt.ID = d3.ID
INNER JOIN X_LAST_TABLE lst 
    ON lst.JOIN_ID = COALESCE(d1.JOIN_ID,d3.JOIN_ID)

(其它,一再的COALESCE也存在于最终打算中 – 一次在最终的Compute Scalar中,一次在内部毗连的内侧).

留意最后的插手.此内毗连(按照界说)是X_LAST_TABLE和前面的毗连输出的笛卡尔积,个中应用了lst.JOIN_ID = COALESCE(d1.JOIN_ID,d3.JOIN_ID)的选择(毗连谓词).笛卡尔积的基数仅为481577 * 94025 = 45280277425.

为此,我们必要确定并应用谓词的选择性.不透明的扩展COALESCE树(按照UNION和IIF,记着)的组合以及对要害信息,派生直方图和早期“不通俗”大都冗余多对多外毗连组合的频率的影响意味着CE无法以任何正常方法得出可接管的预计值.

功效,它进入猜猜逻辑.揣摩逻辑中等伟大,实行了各类“受过教诲”的揣摩和“没那么受过教诲”的揣摩算法.假如没有找到更好的揣摩基本,模子行使最后的揣摩,对付相称较量,它是：sqllang！x_Selectivity_Equal = fixed 0.1 selective(10％guess)：

06002

功效是对笛卡儿积的选择性为0.1：481577 * 94025 * 0.1 = 4528027742.5(~4.52803e 009),如前所述.

重写

当有题目的毗连被注释掉时,发生了更好的预计,由于停止了牢靠选择性“最后的揣摩”(要害信息由1-M毗连保存).预计的质量如故很低,由于COALESCE毗连谓词基础不是CE友爱的.我想,修改后的预计对人类来说至少看起来更公道.

当查询行使外部联接写入最后安排的X_DETAIL_LINK时,开导式从头排序可以将其与最终内部联接互换到X_LAST_TABLE.将内毗连放在题目外毗连旁边,可以提供有限的早期从头排序机遇以改造最终预计,由于大大都冗余的“不通俗”多对多外毗连的影响来自于棘手的选择性预计对付COALESCE.同样,预计数比牢靠揣摩要好一些,而且也许不会经得起在法庭上确定的交错扣问.

从头排序内部和外部联接的殽杂是坚苦且耗时的(纵然第2阶段完全优化仅实行有限的理论移动子集).

在Max Vernon的答复中提议的嵌套ISNULL想法停止纾困的牢靠揣摩,但最终预计是一个不行能的零行(为了正派而晋升到一行).对付计较所具有的全部统计基本,这也可所以1行的牢靠揣摩.

I would expect a join cardinality estimate between 0 and 481577 rows.

这是一个公道的祈望,纵然人们接管基数预计可以在差异的时刻(基于本钱的优化时代)在物理上差异但逻辑上和语义上沟通的子树上产生 – 最终打算是一种最好的拼接在一路的最好的(每个备忘录组).缺乏打算范畴的同等性担保并不料味着小我私人插手应该可以或许歧视尊重,我大白了.

另一方面,假如我们最终揣摩最后的本领,但愿已经失去了,那么为什么还要操心呢.我们实行了全部认识的能力,然后放弃了.假如没有此外,那么狂野的最终预计是一个很好的警示符号,在编译和优化此查询时代并非全部内容都在CE内部完成.

当我实行MCVE时,120 CE为原始查询发生了零(= 1)行最终预计(如嵌套的ISNULL),这与我的思想方法一样令人无法接管.

真正的办理方案也许涉及计划改观,应承在没有COALESCE或ISNULL的环境下举办简朴的等毗连,抱负环境下是外键和其他束缚对查询编译有效.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!