3

为什么通过我的实体模型调用存储过程会导致性能比直接调用慢得多，有什么明显的原因吗？

首先，我不希望 SP 以完全相同的速度运行，而且我知道 EF 必须做的各种事情在直接访问 SP 时不会被调用。

除此之外，我有一个返回三列字符串的查询。当我通过 Enterprise Manager 执行它时，它几乎可以立即运行。如果我通过 EF 运行它，则大约需要六秒钟。当然，结果被映射为复杂类型，但是当我通过 SQL Server Profiler 运行查询时，可以清楚地看到延迟发生在 SQL Server 上：

从 SQL Server Profiler 中的两个来源执行的查询的性能

在图中，1 表示从企业管理器调用的 SQL，2 表示它是通过我的应用程序使用 EF 调用的。

有什么明显的我做错了吗？我预计可能会延迟一两秒，但差异似乎太大了。

编辑：

似乎存储过程在通过 ADO.Net 调用时也运行缓慢。我的同事似乎认为这与 .Net 正在缓存的错误执行计划有关。通过编辑存储过程并再次保存它似乎清除了缓存中的所有内容，并且对存储过程的 ADO.Net 和 EF 调用都运行良好。

有没有其他人遇到过这样的事情？

4

3 回答 3

4

Take a look at this thread on SQL Server forum. It's a bit similar and might give some clues. In short, you may have different SQL Server execution environment options in SSMS and ADO.NET leading to different execution plans. Clearing the SQL Server plan cache should help.

于 2012-04-18T16:46:19.660 回答
2

Pavel Gatilov 似乎已经用 ARITH ABORT 设置击中了这个名字，但我想我会发布更多关于我的发现的信息。

这篇关于 SO 的帖子讨论了一个类似的问题，讨论了一个变通方法；可以在 EF 连接和 SQL.Data.Client 之间编写一个包装类，该类在对数据库的任何调用前加上“SET ARITHABORT ON”。MSDN上的这篇文章更详细地解释了。

在查看了更改的复杂性并考虑到我们要将应用程序从使用存储过程转移到完全使用 EF 之后，我们将硬着头皮将 SP 功能转移到我们的 EF 数据模型中。

于 2012-04-20T08:51:03.957 回答
0

在单个事务中调用不一样

INSERT INTO foo (col1, col2) SELECT col1, col2 (with all 100 rows of the changes)

比调用 100 次

EXEC SP_foo_INSERT param1, param2

只需查看在这两种情况下生成的查询并直接在数据库中测试该查询。看看它的执行计划是什么。

于 2013-08-09T00:58:01.283 回答