DbLinq的对象跟踪性能是否可以提高？

Question

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

我一直在测试中等大小的数据集。 在我现在的特定测试集中，在更新中，最终插入了44个新行并更新了其他81行。 但是，我对SubmitChanges（）的调用最终花费了很长时间-大约3-4分钟，这似乎要花很长时间（我原以为是）才能对数据库进行较少的更改。

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

为了给出一些实际数字，我最近进行了一次测试：

• SubmitChangesImpl中的时间：204884毫秒
  • UpdateEntity中的时间：200908 ms
    • 包含时间：148173毫秒
    • QueryBuilder.GetUpdateQuery中的时间：685毫秒
    • QueryRunner.Update中的时间：28毫秒
    • UpdateReferencedObjects中的时间：49958毫秒

如您所见，构建和运行SQL查询的时间与检查是否存在对我们正在更新的实体的引用所花费的时间相形见（（如果没有引用，则插入该实体，尽管在这种情况下所有已存在的实体）。 虽然我了解为什么会发生这种情况，但为了维护数据完整性等等，这却在破坏这些常规更新操作的性能。

我查看了将ObjectTrackingEnabled设置为false的情况，但这使得DataContext是只读的，这对我没有用-我的问题是更新的性能。

有什么措施可以提高更新性能？ 在尝试在单个提交中推送40-50次插入和80多次更新时，我是否以不太理想的方式使用DbLinq？ 如果是这样，是否有更好的方法来解决？

Answer 1

如果使用寿命长的DataContext，则在其中读取数据，修改数据，提交更改，然后使用同一DataContext对象重复该操作，这可能会对性能产生负面影响。 一旦DataContext实现了一个实体，它将作为对象跟踪的一部分在DataContext的整个生命周期内保留在内部。 随着时间的流逝，此内部缓存可能会变大，在某些情况下，实际上会变成数据库很大一部分的内存中缓存。 这可能会减慢速度，并在SubmitChanges期间导致DataContext进行更多工作。

DataContext是短暂的。 它的寿命应该是一个工作单元。 创建它，将其用于某些东西，然后处置它。

这里有一些更多的细节：

为什么重用DataContext会对性能产生负面影响？

这是由接近产品的人进行的：

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

长期使用：通过查询检索对象后，DataContext本身不会覆盖对象。 因此，随着时间的流逝，如果频繁更改检索到的对象，它们可能会变得过时。

SubmitChanges（）之后的生活：在SubmitChanges（）之后可以使用DataContext，但是必须小心。 SubmitChanges（）进行所有艰苦的工作来弄清您对对象图所做的所有更改。 它为您订购CUD操作，并按每个更改的对象的粒度提供乐观的并发检查。