sp_cursorprepexec 导致 5300 万次读取？

Question

我们正在使用 SQL Server 2012 运行 Dynamics AX 2012 安装。我知道不应再使用游标，但 AX 正在使用它，我们无法更改此行为，因此我们必须使用它。

今天我发现了一个非常糟糕的查询，读取次数超过 5300 万次，执行时间超过 20 分钟。

我通过我们的监控工具 SentryOne 捕获了这个查询。

declare @p1 int
set @p1=1073773227
declare @p2 int
set @p2=180158805
declare @p5 int
set @p5=16
declare @p6 int
set @p6=1
declare @p7 int
set @p7=2
exec sp_cursorprepexec @p1 output,@p2 output,N'@P1 bigint,@P2 nvarchar(5),@P3 bigint,@P4 nvarchar(8),@P5 bigint,@P6 bigint,@P7 bigint,@P8 bigint,@P9 bigint,@P10 bigint,@P11 bigint,@P12 bigint,@P13 bigint,@P14 bigint,@P15 bigint,@P16 bigint,@P17 bigint,@P18 bigint,@P19 nvarchar(5),@P20 bigint,@P21 bigint,@P22 bigint,@P23 bigint,@P24 bigint',N'SELECT T1.PRODUCT,T1.EXTERNALVENDPARTY,T1.LIFECYCLESTATUS,T1.RECID,T2.ECORESPRODUCT,T2.ECORESDISTINCTPRODUCTVARIANT,T2.SGE,T2.ECORESREFORDERNUM,T2.ORDERNUM,T2.RECID,T3.ECORESREFORDERNUM,T3.NAME1,T3.NAME2,T3.NAME3,T3.RECID,T4.ECORESPRODUCT,T4.EXTERNALITEMID,T4.ECORESDISTINCTPRODUCTVARIANT,T4.RECID,T5.RECID,T5.PERSON,T6.RECID,T6.NAME,T6.INSTANCERELATIONTYPE,T7.RECID,T7.NAME,T7.INSTANCERELATIONTYPE,T8.PARTY,T8.ACCOUNTNUM,T8.RECID,T9.RECID,T9.DISPLAYPRODUCTNUMBER,T9.INSTANCERELATIONTYPE,T10.PRODUCT,T10.CATEGORY,T10.RECID,T11.RECID,T11.CODE,T11.NAME,T11.INSTANCERELATIONTYPE FROM INVENTTABLE T1 CROSS JOIN ECORESPRODUCTORDERNUM T2 CROSS JOIN ECORESPRODUCTORDERNUMTRANSLATION T3 LEFT OUTER JOIN VENDEXTERNALITEM T4 ON ((T4.PARTITION=5637144576) AND ((T2.ECORESPRODUCT=T4.ECORESPRODUCT) AND (T4.ECORESDISTINCTPRODUCTVARIANT=@P1))) CROSS JOIN HCMWORKER T5 CROSS JOIN DIRPARTYTABLE T6 CROSS JOIN DIRPARTYTABLE T7 CROSS JOIN VENDTABLE T8 CROSS JOIN ECORESPRODUCT T9 CROSS JOIN ECORESPRODUCTCATEGORY T10 CROSS JOIN ECORESCATEGORY T11 WHERE (((T1.PARTITION=5637144576) AND (T1.DATAAREAID=N''087'')) AND (T1.DATAAREAID=@P2)) AND ((T2.PARTITION=5637144576) AND ((T2.ECORESPRODUCT=T1.PRODUCT) AND (T2.SGE=@P3))) AND ((T3.PARTITION=5637144576) AND ((T3.ECORESREFORDERNUM=T2.ECORESREFORDERNUM) AND (T3.LANGUAGEID=@P4))) AND ((T5.PARTITION=5637144576) AND (T5.RECID=T2.PRODUCTMANAGER)) AND (((T6.PARTITION=5637144576) AND (T6.INSTANCERELATIONTYPE IN (@P5,@P6,@P7,@P8,@P9,@P10,@P11) )) AND (T6.RECID=T5.PERSON)) AND (((T7.PARTITION=5637144576) AND (T7.INSTANCERELATIONTYPE IN (@P12,@P13,@P14,@P15,@P16,@P17,@P18) )) AND (T1.EXTERNALVENDPARTY=T7.RECID)) AND (((T8.PARTITION=5637144576) AND (T8.DATAAREAID=N''087'')) AND ((T7.RECID=T8.PARTY) AND (T8.DATAAREAID=@P19))) AND (((T9.PARTITION=5637144576) AND (T9.INSTANCERELATIONTYPE IN (@P20,@P21,@P22) )) AND (T9.RECID=T1.PRODUCT)) AND ((T10.PARTITION=5637144576) AND (T10.PRODUCT=T9.RECID)) AND (((T11.PARTITION=5637144576) AND (T11.INSTANCERELATIONTYPE IN (@P23,@P24) )) AND (T11.RECID=T10.CATEGORY))',@p5 output,@p6 output,@p7 output,0,N'087',5637146082,N'de',41,2303,2377,2975,2978,5329,6886,41,2303,2377,2975,2978,5329,6886,N'087',3265,3266,3267,2665,4423
select @p1, @p2, @p5, @p6, @p7

我注意到的第一件事是这个查询使用了一个游标。出于好奇，我复制了该语句并在没有游标的情况下在 Management Studio 中执行了它（我必须承认我替换了查询的参数以便我可以运行它）。在 SSMS 中，查询在 30 秒内完成。不是很快，但仍然比游标替代方案快。

在这里，我为您提供两个计划：

• 带光标的计划：https : //www.brentozar.com/pastetheplan/?id=Sk0aMY-Y-
• 没有光标的计划：https : //www.brentozar.com/pastetheplan/?id=HJ6ImtWK-

没有光标的计划仍然是一个非常糟糕的计划，但要好得多。我的问题是：有人可以向我解释为什么游标版本需要 5300 万次读取吗？

使用游标查询的统计信息：

Duration    CPU         Reads       Writes  Est Rows    Actual Rows
1.396.212   1.379.157   53.270.895  3.878   30          2

无游标查询的统计信息：

Duration    CPU         Reads       Writes  Est Rows    Actual Rows
23.337      1.703       665.113     13      4.287       34.813

得到 34,813 行而不是 2 行似乎很奇怪；但我很确定我填写了正确的参数。我认为这可能是 SQL Sentry 的一个有趣的怪癖，因为我只是从那里复制了统计数据。

我希望我能为你提供所有必要的信息。此外，如果有人有一些好的阅读，更好地理解游标会很棒。

Answer 1

首先，令我惊讶的是，来自 SQL Sentry 的两个查询的实际行数并没有或多或少相同。

第二。很难用没有实际计划的光标判断您的估计在计划中有多正确，但有些事情对我来说很突出。（PS：参考我的回答以获得实际计划）。

话虽如此，从您的估计计划中可以注意到几件事。

由于参数化，存在关于不匹配索引的警告。删除参数化以便 SQL Server 可以使用那些无法匹配的参数可以显着改善 I/O。

两个计划之间的估计行数也大幅减少。在带有游标的计划中，来自 vendexternalitem 的估计行数为 11。在没有游标的计划中，估计的实际行数接近 200K。如果您的 200K 记录实际上进入了该假脱机操作员，那可能会很痛苦。

所有运算符的估计值都大不相同（在带有游标的计划中要小得多），因此您的计划可能是使用与您在没有游标的查询中使用的参数值不同的参数值来编译和缓存的。（称为参数嗅探）

在发明表上的索引查找+键查找中还有一个很奇怪的选择。该计划使用 typeIdx，然后对聚集索引 (itemidx) 进行键查找。如果您的估计不在那里，并且 SQL Server 必须进行大量关键查找，这也可以解释大量 IO。我不熟悉您在没有光标的情况下计划中的 stopidx，但它看起来好像在覆盖，因此对于您提供的参数来说，这可能是更好的选择。我想它选择了 typeidx 是因为它要窄得多，但这可能是由于编译时间值与您提供的有问题的执行不同。

简而言之，我将在 AX 中删除此查询的参数化，以便它生成一个包含实际值的计划，以便它选择“更好”的索引，如 SSMS 中的计划（和执行时间）所证明的那样。这也将允许 SQL Server 使用筛选的索引。为此，让开发人员在执行此查询的应用程序代码中添加forceliterals关键字，看看会发生什么。

这可能仍然会给您留下一个需要 30 秒的查询（类似于您在 SSMS 中的查询），但这只是一个调整问题。您的计划中缺少索引警告，例如，我认为 ecoresproductordernum.sge 上的索引可能会有所帮助，但我不知道这些表，并认为它们是通过自定义添加的。一般的调整原则在这里会有所帮助，但对于这个答案来说可能太宽泛了（涵盖索引，......）