Question

嗯，我知道。 '来自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（运行几分之一秒）

执行计划，用于从app执行查询时：http://i.imgur.com/Ra45CAo.png（运行〜3秒）

因此，由于某种原因，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（app，1个执行数，655k估计行数）

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

http://i.imgur.com/pm2k8CS.png（app，655k执行次数，1次估算行数）

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

奇怪的查询性能：从SSMS快速，从app（asp.net）慢

0 个答案: