0

嗯，我知道。“SSMS 快，应用程序慢” ——这听起来很熟悉。可以开始考虑参数嗅探或连接设置。但我想我的情况并非如此。

这就是查询：

SELECT [ST].*, [STL].*
FROM [WP_CashCenter_StockTransaction] AS [ST] 
    LEFT JOIN [WP_CashCenter_StockTransactionLine] AS [STL] ON ([STL] [StockTransaction_id] = [ST].[id]) 
WHERE 
([ST].[Type] IN (0, 1, 10, 9)
AND ([STL].[Direction] IN (0, 1) OR [STL].[id] IS NULL) 
AND [ST].[Status] IN (0,1)
AND ( ([STL].[StockContainer_id] = 300000742600 OR [STL].[id] IS NULL) AND [ST].[StockContainerID] = 300000742600))

如果您不介意（请在评论中说明），我将发布执行计划图片的链接，因为其中会有很多。

我从 SSMS 获得的执行计划：http: //i.imgur.com/DjTypV2.png（运行不到一秒）

执行计划，当它从应用程序执行时用于查询：http: //i.imgur.com/Ra45CAo.png (runs ~3sec)

因此，由于某种原因，sql-server 做出了错误的估计，并且在第二种情况下更喜欢表扫描。

查询是动态构建的，并为 StockContainerID 的每个新值（无参数）生成新计划。

好吧，所以放弃了试图找出问题并只是使用FORCESEEK提示：

SELECT [ST].*, [STL].*
FROM [WP_CashCenter_StockTransaction] AS [ST] WITH(FORCESEEK)
    LEFT JOIN [WP_CashCenter_StockTransactionLine] AS [STL] WITH(FORCESEEK) ON ([STL].[StockTransaction_id] = [ST].[id])

现在，执行计划似乎是相同的：

http://i.imgur.com/orq7Pmx.png（从应用程序执行）。但它仍然需要〜3秒。

看看这个：

http://i.imgur.com/ZFhyWYc.png（SSMS，1次执行次数，1 行估计）

http://i.imgur.com/bIeTE13.png（应用程序，执行次数为 1，估计行数为 655k）

http://i.imgur.com/FERBNQR.png（SSMS，1次执行次数，1 行估计）

http://i.imgur.com/pm2k8CS.png（应用程序，执行次数 655k，估计 1 行）

您应该已经注意到第二个计划使用并行性。我不知道这是否是问题的原因（我认为不是）。

4

0 回答 0