SQL View 在管理控制台中速度很慢，但在 App 层中速度很快

Posted 2023-04-01

【中文标题】SQL View 在管理控制台中速度很慢，但在 App 层中速度很快

【英文标题】：SQL View slow in management console but fast in App Layer

【发布时间】：2016-01-18 13:30:27

【问题描述】：

这是场景：

我们在 SQL Server 数据库中有一个视图 一个 C# MVC（带有实体框架）应用程序正在不同的服务器中运行，并且正在使用此视图。它工作正常，当从 App 层请求数据时运行速度很快，并在不到 2 秒的时间内呈现出来。 从我的本地计算机上，我运行 SQL Server 管理控制台，并尝试在视图上执行完全相同的查询，它需要 45 秒！！！！！！

为什么 SQL Server 需要很长时间才能呈现数据？是应用服务器中的EF缓存数据吗？

更多信息：两种情况下的数据库/实例相同。一切都在 VMWare 基础架构之上。

MVC 中的代码：

   using (var planning = new PlanningEntities())
                
                    this._vwFolderDetailsInstance =
                        (from m in planning.vwFolderDetails
                         where m.Id == id
                         select m).FirstOrDefault<vwFolderDetail>();
                

短信查询窗口中的代码

   select * from dbo.vwFolderDetail
    where ID = (3831)

【问题讨论】：

您是否在两种情况下都针对相同的硬件/服务器执行查询？

是的，相同的数据库/实例和相同的机器。谢谢

您愿意分享查询本身以及如何从 EF 执行它吗？

如果你运行select ID ... from dbo.vwFolderDetail where ID = (3831)会发生什么？它跑得更快吗？此外，EF 不会像您在 SSMS 中编写的那样创建漂亮的查询，启动 SQL 分析器并查看您是否可以跟踪 EF 调用（它可能是列表中最丑陋的 SQL 语句，大量嵌套查询等）然后从 SSMS 运行它以查看它的作用。之后检查每个的执行计划，看看有什么区别......

查询计划（大多数）可能不同。请参阅dba.stackexchange.com/q/9840/10825 和链接文章

【参考方案1】：

谢谢大家，在尝试了不同的方法后，我们发现这段代码给 SSMS 带来了问题：

ROW_NUMBER() OVER(ORDER BY nField DESC) AS RowID

毕竟，我们只需要在 EF (MVC) 中使用这个视图，所以它在那里工作正常没有问题。

为什么在 SSMS 中而不是在 EF 中？看起来 EF 做的事情比我以前想象的要多。我需要进一步挖掘，但现在我找到了原因。

【参考方案2】：

EF 在运行时编译查询，如果再次调用它并且编译器确定它不需要重新编译它，那么它会更快。 （仅限理论） SSMS 是一个大型客户端 SQL 应用程序，当它向数据库发送查询时，谁真正知道它会做什么，当然我们可以通过运行通信跟踪来确定，但我们仍然不知道客户端获取中包含哪些额外时间到通过网络发送查询的地步。 SSMS 可能会尝试优化查询，而 EF 的做法不同。一旦优化，我猜 SSMS 会更快。

EF 是较新的技术，有时较新的技术会更快。我记得网络浏览器第一次出现的时候。在很多方面很明显，上网比旧技术要快得多。主要原因很可能是旧的东西没有针对速度进行优化。相反，它们在具有大量重试逻辑的连接不良的日子里针对准确性进行了优化。旧代码中有很多遗留的东西，这让事情变得很慢。软件越旧，它必须支持的就越多。

【讨论】：

> EF 是较新的技术并不意味着它将查询发送到数据库的方式不同。事实上，它们都使用相同的有线协议。

谢谢阿鲁姆，让我注意的是那是一个视图，查询是在视图上。我知道当我使用 LINQ 或 EF 链接不同的表时，响应会有所不同，然后尝试在 SSMS 查询窗口中重现相同的结果。在这种情况下只是一个视图。执行前是否在 EF 核心中反汇编视图？这是查询：select * from dbo.vwFolderDetail where ID = (3831)