c# - 使 "compute intermediate results in a temp table"SQL 模式适应 LINQ？

Question

我的团队构建了一个 C# 网络应用程序，该应用程序可以生成临时报告，这些报告以不同方式重新组契约(Contract)一组核心 SQL Server 2008 R2 表中的数据。例如，单个“仪表板”页面可能包含每个地区今天的销售额列表、上周销量最低的商品及其趋势列表、表现最好的销售人员列表以及 20 多个其他指标和图表.在幕后，一个典型的仪表板页面将需要在 20 多个不同的表中进行至少 30 次查询。

不幸的是，“卡住”这些数据并预先计算它是不切实际的——我们需要即时获取实时数据。

为了使这些页面更快，我们的技巧是识别提取相同基础数据的不同查询。然后我们从这些基础表计算中间结果，将这些结果缓存到临时表中，然后将该临时表连接到其他表以计算最终结果。使用这种方法，我们通常可以将特定仪表板所需的 I/O 和时间减少 10 倍。

我们的团队希望将相同的模式应用于使用 LINQ-to-SQL 进行数据访问的类似页面。我们喜欢 LINQ 的编程易用性、单元测试等。但是对于上述类型的应用程序，性能很糟糕，在这些应用程序中，我们执行可能部分依赖于相同底层数据的多个查询。

当然，我可以调用 AsEnumerable() 来具体化中间查询结果，但是如果中间结果很大，那么将结果传入和传出 SQL 会抵消性能优势并创建低效的参数化查询带有数百个项目的 IN (@p1, ... ) 子句。

在理想情况下，LINQ-to-SQL 会提供一个 AsServerEnumerable() 方法，该方法会创建一个临时的中间结果表，我可以在不离开数据库的情况下在下游重复使用。

这样的东西存在吗？

如果没有，关于如何使我们的“服务器端中间物化”模式在 LINQ 上良好运行，您有什么建议吗？

附言- 我在上面说的是“临时表”而不是“表变量”，因为临时表往往更适合更昂贵的查询(并行查询计划、非聚集索引等)。但除此之外，以上所有内容也适用于表变量。

Answer 1

不，它在原始 LINQ 中不存在，并且在我所知道的任何 LINQ 样式 API 中都没有预先封装。

如果您忽略 LINQ-to-SQL 的“LINQ”部分并仅使用 db.ExecuteQuery<T>(sql, args)，它可以存在方法，但如果你这样做，你必须注意确保你正在传递一个明确的和开放连接到数据上下文(如果你使用连接字符串方法，连接管理会自动处理，并且您不能保证在操作之间获得相同的连接 - 它可以从池中获取，因此即使它是相同的底层连接，它也会被重置，删除任何临时表).