使用实体框架进行低级 SQL 优化答案

【问题标题】：Low-level SQL optimisation with Entity Framework使用实体框架进行低级 SQL 优化
【发布时间】：2010-12-06 23:18:17
【问题描述】：

在过去使用数据库时，我发现有必要对查询进行低级调整，例如向优化器提供提示，使其应该使用特定的索引或连接顺序。我们目前正在考虑使用实体框架重写我们的数据层；是否使用 EF 会阻止这种低级优化？

在回答this question 时，有人建议重新处理 LINQ 查询是确保针对底层数据库的查询高效的最佳方式，但这肯定与实体框架的既定目标相反代码中的物理层关注点，应该只处理概念层。

一种选择是使用视图。另一种选择显然是调整实体类型的定义查询。但是，这两种方法都是按实体类型操作的，并且优化调整通常只需要应用于表的某些用途，而不是表的所有用途。我担心我最终不得不将伪实体引入概念层以利用这一点，这再次削弱了概念层和物理层的分离。

【问题讨论】：

为了记录，我们使用的是 MySQL 而不是 SQL Server。我无法评论后者的优化器，但在 MySQL 的情况下，它在很多地方选择了次优的执行计划。关于代码中的微优化的标准论点是编译器优化器已经变得如此聪明，以至于你无法击败它们。根据我的经验，SQL 优化器的类似情况似乎还有很长的路要走。

标签： database entity-framework optimization

【解决方案1】：

好吧，既然我写了你提到的答案，也许我应该澄清一下。应该重写糟糕地写成 LINQ 的 LINQ 查询，因为糟糕的 LINQ 很少会变成好的 SQL。所以尽可能写出最好的 LINQ，不是因为你试图调整 SQL 本身，而是因为你需要从本身就很好的东西开始。

但是，除此之外，如果您需要优化特定查询，那么您可能需要映射存储过程。除了让您完全控制之外，这还允许您执行任何 LINQ 实现通常不支持的事情。

【讨论】：

我无意批评您之前的回答，这在上下文中非常合适。但是感谢您的澄清，我当然可以看到编写正确的惯用 LINQ 是理所当然的事情，而不是过早的优化。

【解决方案2】：

我不是实体框架专家，所以我确信其中的某些部分是我误解的，但我知道任何 SQL Server DBA 通常“不愿意”认可 ORM 的原因之一是这个低级代码调优问题尚未得到合理解决。我从一些 EF 拥护者那里得到的普遍印象是，SQL Server 优化引擎在每个版本中都会变得更好，因此对于大多数应用程序来说，这种低级编码不应该是必需的。

话虽如此，如果您需要 SQL Server 的高性能并且您负担不起机器升级费用，那么恐怕您需要继续管理您的 SQL 代码（您也许可以使用 LINQ to SQL） ;如果应用程序很小，并且存储的数据量减轻了对性能的需求，您可能可以使用 EF 并依赖优化器。

【讨论】：

【解决方案3】：

即使编译器会优化您的代码，但如果您编写循环、循环、循环，它会变慢。

如果您使用“Inculde”或“load”加载子表，您将获得不同数量的数据库命中。

编写 LINQ 查询的方式会影响生成的 SQL。

我这样做的方法是通过查看 SQL 分析器中的输出来检查正在生成的 sql。

当我们拥有内存数据库时，我们可能会到达您想去的地方:)

【讨论】：