Linq 强制EF“子查询”中的“前100%”可查询

更新：关于top 100%生成更好的查询计划，我错了。对于大小合理的top N，该计划仍然更好，可能与参数嗅探有关

虽然我仍然认为这个有重点的问题有其优点，但它对我的问题2并不是一个有用的解决方案，可能对你也不是

我遇到了一些SQL Server优化效果不佳的查询。统计数据看起来是正确的，SQL Server选择了“更糟糕”的计划，对数百万条记录执行搜索，尽管估计值和实际值相同，但这个问题与此无关1

在本文中，有问题的查询采用简化形式：

从x中选择* 加入…的行列。。 加入z on。。 其中z.q=。。 但是，由于我对基数更为了解，显然，以下表格始终会产生更好的查询计划：

从x中选择* 参加 -这里的结果集“非常小” 选择前100%* 从今以后。。 加入z on。。 其中z.q=。。t on。。 在L2S中，Take函数可以用来限制到top N，但这种方法的问题是需要有限/固定的N，这样一些查询就可以假设中断，而不是在强制物化的情况下运行得非常慢

虽然我可以为前N选择一个“非常大”的值，但讽刺的是，对于最初的问题，这会随着N值的增加而增加SQL查询执行时间。预期的中间结果预计只有几十到几百条记录。我当前的代码运行了前100个，然后，如果检测到这样的代码包含了太多的结果，则再次运行查询，没有限制：但这感觉像是一个乱七八糟的东西。。在一片混乱之上

那么问题是：EF/L2E/LINQ查询能否生成与EF可查询上的前100%相同的结果

通过ToList强制实现物化不是一个选项，因为结果应该是EF可查询的，并且保持在LINQ to实体中，而不是LINQ to对象中

虽然我目前正在处理EF4，但如果这[仅]在EF的更高版本中是可能的，我会接受这样的答案——这是有用的知识，并且确实回答了所问的问题

1如果希望回答“不要这样做”或其他选择，请将其作为次要答案或与实际问题的答案一起放在一旁。否则，请随意使用评论

2除了前100%没有生成更好的查询计划外，我还忘记了涉及到的“核心问题”，即糟糕的参数嗅探实例是SQL Server 2005

以下查询需要很长时间才能完成，而直接变量替换在眨眼之间运行，这表明参数嗅探存在问题

声明@x int 设置@x=19348659 选择 作品* 来自OrderElement oe 在oe.OrdersElementID=rp.OrdersElementID上加入OrderRatePlan rp 在rp.OrdersRatePlanID=op.OrdersRatePlanID上加入OrderPrice op 其中oe.OrdersProductID=@x 含糊不清但可行的查询

选择 作品* 来自OrderPrice op 参加 -选择“较小的N值”运行速度很快，并且随着 -当N>>1000花费的时间太长时，N的值会增加。 -使用前100%也需要太长时间。 选择前100名 卢比* 来自OrderElement oe 在oe.OrdersElementID=rp.OrdersElementID上加入OrderRatePlan rp 其中oe.OrdersProductID=@x 反相 在rp.OrdersRatePlanID=op.OrdersRatePlanID上

---

是的，您可以自己查询

db.SqlQuery<something>("SELECT * FROM x ...");

---

你不能传递一个int.MaxValue吗？@xanatos是的，尽管我在使用这种策略的问题上增加了一点。为什么你需要100%的TOP？如果不使用，查询计划是否不同？如果你在没有顶部的情况下进行第二次查询，我认为你不能让EF生成这样的SQL，我从来没有看到它包含任何类似的内容。我认为这是一种XY问题。与其看如何去做，不如重新评估它的需求，找到另一种方法来改进执行计划。顺便说一句，我从来没有发现任何情况下，如果其他一切都是正确的统计数据，你所声称的优化查询的方法实际上会这样做，在少数情况下，我发现这可能会有所帮助，因为一个更了解情况的DBA做了坏事。我想看看LINQ生成的查询，它试图优化LINQ查询，但假设它将按照您设定的方式生成它，这可能是不正确的，并且浪费了尝试优化一些实际上永远不会发生的事情。我不介意答案中有一个相关的旁白，在哪里它会更明显-只是要确保它没有采取的答案！我经常在底部添加一个--region。它似乎与参数嗅探有关，而在EF中通常是无法避免的。。只能在使用变量时在SSMS中复制。无论如何，这似乎回答了我的问题——尽管它可能被误导了 一点也不重要，但并不是所有的查询都会发生这种情况。如果我还记得的话，它也是在SQLServer2005上的，而且只有在存储过程中才会出现。