我有一些LINQ的复杂查询，在幕后做大约7-9个连接。我正在优化查询。现在我对这里的一些事情感到困惑 -
我是否应该只使用存储过程执行动态sql而不是将其作为LINQ查询。何时应该让存储过程执行而不是使用LINQ < / strong>查询？我想这取决于......但最佳做法是什么？什么时候应该有存储过程？我看到有时候LINQ会在幕后做一些奇怪的低效事情吗？这是我的担忧..
我可以用多次选择 ...比较我可以加入表格但是如果加入它们就会变得更复杂（比如7-9连接）如比较至3-5选择）。我认为个人加入会有效吗？既然只有一个数据库请求？有多个选择，它必须发出多个请求？你对此有什么想法 ？
答案 0 :(得分：2)
有许多因素在这里有所贡献，而且我有很多未知数，所以我的答案的潜台词是“它取决于”。
1）使用定义良好的Datacontext LINQ-to-SQL通常会生成有效的查询。过滤器自动参数化，使数据库引擎能够缓存执行计划。因此，我认为只有在需要查询提示或查询生成器不支持的其他一些机制时，存储过程才会表现得更好。我认为最好的做法是使用LINQ，只有在可以证明显着的优化时才使用sprocs。
2）通常限制您到DB的行程是最佳的。但是阅读你们关系中所需的联接数量会让你想知道你是否可以通过添加一个View来获得良好的服务。它将抽象复杂性，视图与LINQ很好地集成，它可以保护您的代码免受未来架构更改的影响。
我还建议LINQPad帮助优化LINQ-to-SQL查询。它已经成为我不可或缺的工具，如果你还没有使用它，我打赌它也将成为你的一个。
此外，有关LINQ与SProcs的更多意见，请查看此问题中的讨论：LINQ-to-SQL vs stored procedures?