.net - Linq 查询超慢？

Question

我从 sql profiler 复制了 linq 构建的 sql 查询，这就是它的烦人之处:

1. 它前缀 select ..columnNames.. from (select ..columnNames.. from (select cNames from view)点评:这里的2个select语句是不必要的。

2. 执行此查询需要 14 秒

3. 当我删除最后一行，其中包含所有参数(如 @p_linq_0 ..)并在 where 条件中填充参数值并执行完全相同的动态查询时，需要 1秒或更短。即使如此，从 sql studio 执行该查询也需要 0 秒。这真是 linq 的蹩脚。

我可能会将其移至存储过程，但我现在害怕使用 linq

经过进一步研究，我发现:

查询1:

exec sp_executesql N'SELECT * from TableView WHERE Id = @Id', N'@Id int', @Id = 1

查询2:

exec sp_executesql N'SELECT * from TableView WHERE Id = 1'

查询 1 需要 12 秒，查询 2 需要 0 秒。这就解释了为什么 linq 查询很慢。那么现在，这是否意味着我应该始终使用存储过程，还是我遗漏了一些东西？

为什么 Microsoft 不能修复 Linq 查询构建，解析该字符串并替换参数值而不是将这些参数作为参数传递给 sp_executesql 有多困难

Answer 1

我和你在一起。我的意思是，您可能会发现您发现的这种灾难性性能打击的原因并找到补救措施。但实际上，Linq to SQL 会发生这种情况，并且花费额外的时间来优化 Linq 语句，以便 SQL 查询在后端具有更高的性能，这与目的背道而驰。 Linq 应该让事情变得更容易。

我个人使用 Linq-to-SQL 或 Entity Framework 对单个记录执行 CRUD 操作。然后，对于任何大型 SELECT 语句，我将像以前一样简单地编写一个存储过程。这似乎是生产力和性能之间的良好折衷，对我来说效果很好。

编辑:事实上， Entity Framework 人员已经预料到了这一点。 Entity Framework 与存储过程配合得很好。您可以add a stored proc to your Entity Framework model并获得所有强类型的好处。然后您可以从代码调用该存储过程。