存储过程的性能＆amp;实体框架

Question

有没有明显的理由为什么通过我的实体模型调用存储过程会导致性能远远低于直接调用它？

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

除此之外，我有一个返回三列字符串的查询。当我通过企业管理器执行它时，它几乎立即运行。如果我通过EF运行它，那么大约需要六秒钟。当然，结果被映射到一个复杂的类型，但是当我通过SQL Server Profiler运行查询时，很清楚地看到SQL服务器上发生了延迟：

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

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

修改

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

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

Answer 1

看看this thread on SQL Server forum。它有点相似，可能会提供一些线索。简而言之，您可能在SSMS和ADO.NET中具有不同的SQL Server执行环境选项，从而导致不同的执行计划。清除SQL Server计划缓存应该有所帮助。

Answer 2

Pavel Gatilov似乎在ARITH ABORT设置中名列前茅，但我想我会发布更多有关我的发现的信息。

SO上的{p> This post涵盖了类似的问题，讨论了一项解决方法;可以在EF连接和SQL.Data.Client之间编写一个包装类，它使用“SET ARITHABORT ON”对DB的任何调用作为前缀。 MSDN上的This article更详细地解释了。

考虑到这些变化的复杂性，并考虑到我们要将应用程序从使用存储过程转移到完全使用EF，我们将紧紧抓住机密，并将SP功能转移到我们的EF数据模型中。

Answer 3

单个交易中的呼叫不一样

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

比调用100次

EXEC SP_foo_INSERT param1, param2

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