DbLinq的目标跟踪性能能得到改善吗？

Question

我有一个ASP.NET MVC2站点，通过DbLinq连接到MySQL数据库。有一组特定的操作在站点上定期执行，包括在几个表中遍历一组特定的记录并更新它们，并在其他一些表中添加一些新的记录。

我一直在用一组中等大小的数据进行测试。在我现在特定的测试集中，在更新时，它最后插入了44行，并更新了81行。但我对SubmitChanges()的调用最终花费了很长的时间-- ~3-4分钟，这似乎需要很长时间才能对DB进行相对较少的更改(我认为是这样)。

最后，我做了一些简单的分析，发现问题似乎不是在数据库上执行查询，甚至不是构建查询。大部分时间似乎被UpdateEntity内部对AllTrackedEntities.ContainsReference()的调用占用了。

为了给出一些实际数字，在最近的一次测试中，我有：

• Time in SubmitChangesImpl: 204884 ms
  • Time in UpdateEntity: 200908 ms
    • Time in ContainsReference: 148173 ms
    • Time in QueryBuilder.GetUpdateQuery: 685 ms
    • 时间QueryRunner.Update: 28 msH 210H 111时间( UpdateReferencedObjects: 49958 )

​

​

如您所见，构建和运行SQL查询与检查是否存在对我们正在更新的实体的引用(如果没有引用，则插入实体，尽管在本例中所有更新的实体都存在)相比显得相形见绌。虽然我理解发生这种情况的原因，为了维护数据完整性等等，但这会降低这些常规更新操作的性能。

我看过将ObjectTrackingEnabled设置为false，但这使得DataContext是只读的，这对我来说没有用--我的问题是在更新时的性能。

有什么措施可以改善更新的性能吗？我是否以一种不太理想的方式使用DbLinq，试图在一次提交中完成40-50个插入和80+更新？如果是的话，是否有更好的方法来解决这个问题？

Answer 1

如果使用长寿命的DataContexts，即读取数据、修改数据、提交更改，然后重复使用相同的DataContext对象，则会对性能产生负面影响。一旦一个DataContext实现了一个实体，它就会将它保存在DataContext的生命周期内，作为其对象跟踪的一部分。随着时间的推移，这个内部缓存可能会变得很大，在某些情况下实际上会成为数据库中很大一部分的内存缓存。这可以使事情慢下来，并在SubmitChanges期间为SubmitChanges带来更多的工作。

DataContext注定是短暂的.它的寿命应该是一个工作单位。创造它，用它做某事，然后处理它。

下面是一些更详细的内容：

Why would reusing a DataContext have a negative performance impact?

这是一个与产品关系密切的人说的：

http://blogs.msdn.com/b/dinesh.kulkarni/archive/2008/04/27/lifetime-of-a-linq-to-sql-datacontext.aspx

长期使用:DataContext本身不会覆盖通过查询检索对象的对象。因此，随着时间的推移，检索到的对象可能会变得陈旧，如果它们经常被更改。

SubmitChanges()之后的生活: DataContext可以在SubmitChanges()之后使用，但必须小心。SubmitChanges()完成了计算对对象图所做的所有更改的所有艰苦工作。它为您排序CUD操作，并在每个更改对象的粒度上提供乐观的并发检查。。