语句查询性能：从SSMS快速，从应用程序慢速（asp.net）

嗯，我知道“从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获得的执行计划：（运行一秒的分数）

执行计划，从应用程序执行时用于查询：（运行~3sec）

所以，出于某种原因，SQLServer做出了错误的估计，在第二种情况下，它更喜欢表扫描

查询是动态构建的，并且为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]) 

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

（从应用程序执行）。但仍然需要约3秒

看看这个：

（SSM，1个执行数，1个估计行）

（应用程序，1次执行，655k估计行）

（SSM，1个执行numebr，1个估计行）

（应用程序，655k执行数，1个估计行）

---

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

应用程序执行的查询是什么？在第一个查询中，您有一个where子句，它在联接之前减少从每个表返回的列。如果将相同的子句添加到第二个查询，使用FraceSek的一个查询，它仍然需要3秒吗？在执行任何查询速度测试之前，请考虑执行<代码> DccCyFrutcCux。除非是生产服务器。我在两个查询中都有

where

条件（实际上只有一个查询，我只是从SSMS运行它）。是的，我已经执行了

DBCC FREEPROCCACHE