Question

如果可以，请提供建议......

我的项目基于Linq-To-SQL，而且（差不多）完成的应用程序的性能非常差。我多次启动SQL事件探查器以使用LoadOptions优化查询以减少到数据库服务器的往返次数，但在一天结束时，我的共同点被编织成以下几点：

微软的官方建议是，DataContext 不的生命周期很长 - 也就是说 - 他们建议您创建一个DataContext，实现对象，进行更改，调用SubmitChanges（），然后处置。我的申请虔诚地遵循这种模式。
DataContext往往对它的实体非常紧贴，并且当涉及到更改跟踪和延迟关系加载时，已经证明将对象从一个上下文分离和重新附加（未更改）对象是有问题的。重新附加对象。因此，保持加载的对象缓存已被证明是有问题的。
在DataContext上设置LoadOptions以加载多层关系时，性能会受到影响，因为结果数据是相关行的乘积，而不是它们的总和。我正在从字面上提取数据的特定模式导致在设置LoadOptions时返回的数据的卷增加144倍，因此自然这最终成为性能杀手，而不是帮助者。 / p>
如果没有设置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 希望这会有所帮助。

Answer 2

我认为你可以找到一个数据库分析器来检查你的LInqtoSQL程序发送给数据库的SQL语句，并从中找到可以优化的东西

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

2 个答案: