过去使用数据库时，我发现有必要对查询进行低级调整，例如向优化器提供应该使用特定索引或连接顺序的提示。我们目前正在考虑使用Entity Framework重写我们的数据层;使用EF的情况是否会阻止这种低级优化？
在回答this question时，有人建议重新编写LINQ查询是确保对底层数据库的查询有效的最佳方法，但这肯定与实体框架的既定目标相悖。应该将物理层问题与代码分开，代码应该只处理概念层。
一种选择是使用视图。另一个选择显然是调整实体类型的定义查询。但是，这两种方法都是按实体类型运行，并且通常只需要对表的某些用途应用优化调整，而不是每次使用表。我担心我最终不得不将伪实体引入概念层，以便利用这一点，再次减损概念层和物理层的分离。
答案 0 :(得分：1)
我不是实体框架专家，因此我确信其中有一部分我误解了，但我确实知道任何SQL Server DBA“不愿意”支持ORM的原因之一是这个针对性能的低级代码调优问题尚未得到合理解决。我从一些EF粘合剂中获得的一般氛围是SQL Server Opimization Engine在每个版本中都会变得更好，因此大多数应用程序都不需要这样的低级编码。
话虽如此，如果您需要从SQL Server获得高性能并且无法承担机器升级费用，那么我担心您需要继续管理您的SQL代码（您可以使用LINQ to SQL） ;如果应用程序很小，并且存储的数据量减少了对性能的需求，那么您可以使用EF并依赖优化器。
答案 1 :(得分：1)
好吧，既然我写了你提到的答案，也许我应该澄清一下。应该重写错误编写为LINQ 的LINQ查询，因为错误的LINQ很少成为好的SQL。因此，尽可能编写最好的LINQ，不是因为你本身就试图调整SQL，而是因为你需要从自己的条件开始做好事。
然而，除此之外，如果您需要优化特定查询，那么您可能希望映射存储过程。除了为您提供全面控制外，还允许您执行任何LINQ实现中通常不支持的操作。
答案 2 :(得分：0)
即使编译器会优化代码，如果你编写循环，在循环中，在循环中它会变慢。
如果您使用“Inculde”或“load”加载子表，您将获得不同数量的数据库命中。
编写LINQ查询的方式将影响生成的SQL。
我这样做的方法是通过查看SQL profiler中的输出来检查正在生成的sql。
当我们在内存数据库中时，我们可能会到达您想要的位置：）