C# 为什么这个存储过程在ManagementStudio中执行得很快，而在应用程序中执行得不快？

我将此查询作为存储过程：

SELECT     ID
    FROM         dbo.tblRentalUnit
    WHERE     (NOT EXISTS
        (SELECT     1 AS Expr1
        FROM          dbo.tblTenant
        WHERE      (dbo.tblRentalUnit.ID = UnitID)))

在Microsoft SQL Server Management Studio Express中，它的执行时间为16毫秒。当我将它放入Visual Studio 2008自动生成的类型化数据集中时，它的执行时间为64453毫秒。超过一分钟

估算和执行计划如下所示：

Select [0%] <- Filter [1%] <- Merge Join (Left Outer Join) [28%] <- Index Scan [16%] <- Sort [43%] <- Clustered Index Scan [12%]

---

选择[0%]听起来像是缓存不正确的查询计划

你的索引和统计数据是最新的吗

顺便说一句，如果tblTenant.UnitId是tblRentalUnit.ID的外键 然后可以将查询重写为：

SELECT ru.ID    
FROM         
    dbo.tblRentalUnit ru
    LEFT JOIN dbo.tblTenant t ON ru.ID = t.UnitID
WHERE
    t.UnitID IS NULL

---

您是否在每次测试之前刷新缓冲区（从任一客户端）？确保在每次测试之间执行DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE。

tblRentalUnit.ID索引是否正确？

如果需要有关安装的更多信息，请告诉我！为什么会被否决？可能是因为蓝天、绿草和东边升起的太阳。这总是一个很好的理由……我想。我真的不知道为什么会被否决；在我看来还行（虽然可能是dup，但没有人投票给dup）。。。您可能还想在此处阅读答案：确保它不是生产箱！；）我做到了，它也不是一个生产框：）我如何检查并查看我的索引和统计数据是否是最新的？根据数据库的属性，它们自动更新切换到此查询并设置arithaport ON；在应用程序中将执行时间降低到5859毫秒，但它仍然与管理研究中的执行方式不同。在SSMS中，查看估计和实际执行计划的差异（可能在此处发布）两者之间没有差异。我会把它附加到我的问题上，虽然是的。所有内容都已编制索引，此查询中的所有内容都仅对索引起作用。编制索引的“所有内容”可能是问题的一部分。你是如何调整索引的？