查询在 ASP.net 和 Profiler 中很慢，但在 SQL Management Studio 2014 中很快答案

【问题标题】：Query is very slow in ASP.net and Profiler, but fast in SQL Management Studio 2014查询在 ASP.net 和 Profiler 中很慢，但在 SQL Management Studio 2014 中很快
【发布时间】：2016-07-20 10:34:32
【问题描述】：

我有一个在 ASP.NET (EF Linq) 中运行大约需要 40 秒的 MS SQL 查询。我在 Profiler 中捕获了它，它显示了大约 40 秒的持续时间：

但是，当我在 SQL Management Studio 中复制/粘贴它时，它会在 00:00:00 秒内运行。这是一个简单的select 在单个表上（没有联接、视图、存储过程），它返回大约 10.000 行。

执行计划：

我读到this question on StackOverflow女巫指向this blog并放置

设置 ARITHABORT 关闭

在 Management Studio 中的查询上方，但这并不会使其变慢，所以我认为这不是问题所在。

一个奇怪的事情是，我们将应用程序迁移到使用 Windows 2012 / SQL 2014 Web 版的更快的服务器上，从那时起查询似乎运行得更慢了。在我们使用 SQL Express 2008R2 的旧 Windows 2008R2 Server 上，同样的查询确实运行得更快。

【问题讨论】：

有许多SET 选项会产生显着的影响，但默认情况下并不相同。我会尝试的第一件事是在 SSMS 和原始 ADO.NET 中运行类似 mssqltips.com/sqlservertip/1415/… 的东西（您可能需要破解查询以使其友好，因为从 ADO.NET 使用 PRINT 很痛苦, 但是：也许两者都只是select @@OPTIONS 就足够了）。查看哪些标志（如果有）不同。我将在本地尝试检查。
嗯，在本地检查，唯一的增量是您已经在处理的 ARITHABORT。那么，我想知道这是否是错误的参数优化/查询计划生成。如果您自己编写 SQL，则可以使用 OPTIMIZE FOR / UNKNOWN 提示。如果您不是自己编写 SQL：那么...是的，这很棘手。我们必须经常这样做——奇怪的是，在内部我们称之为“Jon Skeet / 新用户问题”——我们的数据布局往往严重偏向于新用户和像 Jon 这样的大量参与用户。
@Marc，感谢您的帮助。 SQL Studio 给出了Options = 5496，但从我的应用程序（在实体框架上下文中创建了一个IDbConnection）它给出了Options = 5432。区别确实是ARITHABORT。
可能你在 EF 中延迟加载相关字段。如果启用延迟加载，请禁用它并重试
我不知道你的表的记录数，但我看到你有一个参数 Date 从 1900-01-01 中选择，这意味着全表扫描，除非你有一个AppCustomerId 上的正确索引。如果您可以发布表和索引定义会有所帮助

标签： asp.net sql-server linq sql-server-2014 database-administration

【解决方案1】：

看起来返回的列中的数据量是问题所在。我将它缩小到所需的最小列集，它变得更快了。我预计文本列会特别减慢应用程序中的速度，但它似乎不会影响 Management Studio 中的相同查询。

PS。在注意到性能提升后，我用原始 SQL 重写了整个内容，查询持续时间降至近 0 秒。

【讨论】：

【解决方案2】：

我认为某些行已被另一个影响您尝试获取的数据的操作锁定，但尚未提交。试试这个作为你的选择语句

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT * FROM tblA WHERE something

【讨论】：