sql-server – 创建缓存(延迟假脱机)CTE结果的计划指南

我通常首先构建一个使用正确计划的查询,然后将其复制到不相似的查询,从而创建计划指南.但是,这有时很棘手,尤其是在查询不完全相同的情况下.从头开始创建计划指南的正确方法是什么？

SQLKiwi已经提到在SSIS中制定计划,有没有办法或有用的工具来帮助为SQL Server制定一个好的计划？

有问题的具体实例是CTE：SQLFiddle

with cte(guid,other) as (
  select newid(),1 union all
  select newid(),2 union all
  select newid(),3)
select a.guid,a.other,b.guid guidb,b.other otherb
from cte a
cross join cte b
order by a.other,b.other;

是否有任何方法可以使结果出现3个不同的guid而不是更多？我希望将来能够更好地回答问题,包括计划指南和多次引用的CTE类型查询,以克服一些SQL Server CTE怪癖.

解决方法

Is there ANY way to make the result come up with exactly 3 distinct guids and no more? I’m hoping to be able to better answer questions in
future by including plan guides with CTE-type queries that are
referenced multiple times to overcome some SQL Server CTE quirks.

今天不行.非递归公用表表达式(CTE)被视为内联视图定义,并在优化之前扩展到它们被引用的每个位置的逻辑查询树中(就像常规视图定义一样).您的查询的逻辑树是：

LogOp_OrderByCOL: Union1007 ASC COL: Union1015 ASC 
    LogOp_Project COL: Union1006 COL: Union1007 COL: Union1014 COL: Union1015
        LogOp_Join
            LogOp_ViewAnchor
                LogOp_UnionAll
                    LogOp_Project ScaOp_Intrinsic newid,ScaOp_Const
                    LogOp_Project ScaOp_Intrinsic newid,ScaOp_Const

            LogOp_ViewAnchor
                LogOp_UnionAll
                    LogOp_Project ScaOp_Intrinsic newid,ScaOp_Const

注意两个View Anchors以及在优化开始之前对内部函数newid的六次调用.然而,许多人认为优化器应该能够识别扩展的子树最初是单个引用的对象并相应地简化.还有几个允许显式实现CTE或派生表的Connect requests.

更一般的实现将使优化器考虑实现任意公共表达式以提高性能(带有子查询的CASE是今天可以发生problems的另一个示例).微软研究院published a paper(PDF)就在2007年,尽管迄今仍未实现.目前,我们仅限于使用表变量和临时表等显式实现.

SQLKiwi has mentioned drawing up plans in SSIS,is there a way or useful tool to assist in laying out a good plan for SQL Server?

这只是我的wishful thinking,远远超出了修改计划指南的想法.原则上,可以编写一个工具来直接操作show plan XML,但是如果没有使用该工具的特定优化器工具,对用户来说可能是一种令人沮丧的体验(并且开发人员会想到它).

在这个问题的特定背景下,这样的工具仍然无法以多个消费者可以使用的方式实现CTE内容(在这种情况下将两个输入都馈送到交叉连接).优化器和执行引擎确实支持多用户线轴,但仅用于特定目的 – 不能将其应用于此特定示例.

While I’m not certain,I have a fairly strong hunch that the RelOps can be followed (Nested Loop,Lazy Spool) even if the query is not exactly the same as the plan – for instance if you added 4 and 5 to the CTE,it still continues to use the same plan (seemingly – tested on SQL Server 2012 RTM Express).

这里有一定的灵活性. XML计划的广泛形状用于指导搜索最终计划(尽管许多属性被完全忽略,例如交换机上的分区类型),并且正常搜索规则也相当宽松.例如,禁用基于成本考虑的备选方案的早期修剪,允许明确引入交叉连接,并忽略标量操作.

有太多细节需要深入研究,但不能强制使用过滤器和计算标量的位置,并且表格column = value的谓词是一般化的,因此包含X = 1或X = @X的计划可以应用于包含X = 502或X = @Y的查询.这种特殊的灵活性有助于找到一个强制性的自然计划.

在具体示例中,常量Union All始终可以实现为常量扫描;联盟所有人的投入数量无关紧要.

（编辑：财气旺网 - 财气网）

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