Question

我有这个Linq查询：

DataBase
    .GroupBy(data => new { data.X, data.Y }, (key, group) => new
    {
        key.X,
        key.Y,
        Somethings = group.Sum(x => x.Something),

        [Code shortened for brevity]

    })
    .OrderBy(row => row.X)
    .ThenBy(row => row.Y)

使用Linq-to-SQL时，它可以很好地转换为我期望的SQL查询，例如：

SELECT [t1].[x] AS [X], [t1].[y] AS [Y], [t1].[value] AS [Somethings], [...]
FROM (
    SELECT SUM([t0].[something]) AS [value], [...], [t0].[x], [t0].[y]
    FROM [table] AS [t0]
    GROUP BY [t0].[x], [t0].[y]
    ) AS [t1]
ORDER BY [t1].[x], [t1].[y]

以上几点是数据库中执行的SUM。但是，使用实体框架核心（2.0）中的Linq-to-Entity，我得到如下内容：

SELECT [data0].[x], [data0].[y], [data0].[something], [...]
FROM [table] AS [data0]
ORDER BY [data0].[x], [data0].[y]

这次没有总结数据库级别的数据（而是在获取所有数据后的内存中）。很多的时间应该不足为奇。

我已经搜索过并发现了类似的问题，但我没有得到任何关于它如何转换为我的特定查询的信息。我有两个问题：

如何使用Linq-to-Entities生成优化结果（在数据库级别汇总）？
作为奖励，如果您知道解释这背后的某种推理，那么所有行为都可以预测？

（我知道我可以使用DbCommand或其他东西来执行特定的SQL，但这不是我正在寻找的答案 - 我想要Linq;）

[编辑] 有人建议this question and its answer使我的问题与此相同。在发表我自己的问题之前，我读到了Q'n'A，但并不满意。以下是我的一些原因：

答案中声称GroupBy始终在内存中处理似乎没有事实证明（但更多内容如下）。
其他问题是关于生成（除其他事项）错误的特定查询，答案包含该问题的解决方案，这不适用于我的情况。
另一个问题 - 或者更确切地说是答案 - 没有专门解决性能问题（我的上下文），并且没有太多关于Linq查询如何在EF Core中转换为SQL的讨论。
~~答案是在没有引用版本等声明的情况下提出声明，并且可能很快就会过时。~~

那么，GroupBy - 内存中的声明怎么样？好吧，我同意这条信息与我的案子有关。如果在内存中执行分组，显然无法在数据库级别对组进行总结。在上述答案的评论部分，确实还提到了我之前忽略的EF Core Road-map。根据我收集的内容，适当的分组将包含在2017年第四季度的2.1版本中。

我现在认为，在EF Core 2.1发布之前，我的问题的答案应该是文档和路线图的明确参考。如果我所拥有的实际总结问题将与分组问题一起解决，还有待观察。（我不明白为什么它不应该，但仍然......）

当有新信息可用时，可以更新这样的答案。

实体框架核心组中的总和性能问题

0 个答案: