linq-to-sql - 有什么方法可以提高 Linq-To-SQL 的性能？

Question

可以的话请多多指教...

我的项目基于 Linq-To-SQL，并且(几乎)完成的应用程序的性能非常差。我已经多次启动 SQL Profiler 以使用 LoadOptions 优化查询，以减少到数据库服务器的往返次数，但归根结底，我的难题被编织成以下几点:

Microsoft 的官方建议是 DataContext 不应有很长的生命周期 - 也就是说 - 他们建议您创建一个 DataContext，具体化对象，进行更改，调用 SubmitChanges()，然后处理。我的申请虔诚地遵循这种模式。

DataContext 往往非常依赖它的实体，当涉及到重新附加对象的更改跟踪和延迟关系加载时，将(未更改的)对象从一个上下文分离和重新附加到另一个上下文已被证明是有问题的。因此，保持加载的对象缓存已被证明是有问题的。

当在 DataContext 上设置 LoadOptions 以加载多层关系时，性能会受到影响，因为结果数据是相关行的乘积，而不是它们的总和。我从字面上提取数据的特定模式导致设置 LoadOptions 时返回的数据量增加 144 倍，因此自然而然地这最终成为性能杀手，而不是助手。

在没有设置 LoadOptions 的情况下(或者甚至在降低级别设置它时)，DataContext 会对数据库执行数百次往返。

我还注意到 DataContext 忽略了第一次通过关系访问对象时已经加载了对象......例如:

Dim allCustomers as Customers() = Context.Customers.ToArray()
Dim allOrders as Orders() = Context.Orders.ToArray()

For Each o as Order in allOrders
    Console.WriteLine(o.Customer.Name)      ' <- Triggers round-trips to database!!!
Next

总之，我遇到的问题是我的客户无法接受我获得的性能，并且:

持有一个单一的、应用程序范围的 DataContext 是不明智的。

缓存和重新附加实体(表面上)是有问题的。

DataContext.LoadOptions 具有深层的多级关系，会影响性能

预加载整个表的数据无济于事 - 当访问外键关系时，DataContext 仍会刷新加载的对象。

我真的觉得我在这里错过了一些基本的东西，也许是在我采用的整体设计模式中，并且希望您提供任何关于从 DataContext 中获取加载的 Object-Graph 而无需所有往返的建议的花絮或臃肿的网络流量。

你的建议？

Answer 1

请看一下网站，
http://www.sidarok.com/web/blog/content/2008/05/02/10-tips-to-improve-your-linq-to-sql-application-performance.html
希望这可以帮助。