LINQ 和存储过程之间的性能差异
LINQ-to-SQL 与存储过程?
我听说过很多关于预编译存储过程的优点的讨论.但是 LINQ 和存储过程在选择、插入、更新、删除上的实际性能差异是什么?有没有人进行任何测试以查看是否有任何重大差异.我也很好奇更多的交易是否会产生影响.
I have heard a lot of talk back and forth about the advantages of stored procedures being pre compiled. But what are the actual performance difference between LINQ and Stored procedures on Selects, Inserts, Updates, Deletes? Has anyone run any tests at all to see if there is any major difference. I'm also curious if a greater number of transactions makes a difference.
我的猜测是 LINQ 语句在第一个事务之后被缓存，性能可能几乎相同.想法?
My guess is that LINQ statements get cached after the first transaction and performance is probably going to be nearly identical. Thoughts?
推荐答案
LINQ 应该在性能上接近，但我不同意上面说 LINQ 更快的说法，它不可能更快，它可能就像不过很快，其他条件都一样.
LINQ should be close in performance but I disagree with the statement above that says LINQ is faster, it can't be faster, it could possibly be just as as fast though, all other things being equal.
我认为不同之处在于，知道如何优化并使用存储过程的优秀 SQL 开发人员在性能上总是略有优势.如果你不擅长 SQL，让 Linq 为你解决，你的表现很可能会被接受.如果您是一名强大的 SQL 开发人员，如果您的应用需要，可以使用存储过程来挤出一点额外的性能.
I think the difference is that a good SQL developer, who knows how to optimize, and uses stored procedures is always going to have a slight edge in performance. If you are not strong on SQL, let Linq figure it out for you, and your performance is most likely going to be acceptable. If you are a strong SQL developer, use stored procedures to squeeze out a bit of extra performance if you app requires it.
如果您编写糟糕的 SQL 来编写一些执行速度比 Linq 慢的存储过程，这当然是可能的，但是如果您知道自己在做什么，那么存储过程和 Datareader 就无敌了.
It certainly is possible if you write terrible SQL to code up some stored procedures that execute slower than Linq would, but if you know what you are doing, stored procedures and a Datareader can't be beat.
相关文章