我有一个通过 DbLinq 连接到 MySQL 数据库的 ASP.NET MVC2 站点。网站上有一组定期完成的特定操作，包括循环处理几个表中的一组特定记录并更新它们，以及在其他一些表中添加一些新记录。
我一直在使用中等大小的数据集进行测试。在我现在的特定测试集中，在更新时它最终插入 44 个新行并更新 81 个其他行。但是我对 SubmitChanges() 的调用最终花费了很长时间 - ~3-4 分钟，这似乎是一个很长的时间来插入(我认为是)对数据库进行相对较少的更改。
我最终做了一些简单的分析，发现问题似乎不在于在数据库上执行查询，甚至不在于构建查询。大部分时间似乎都被 UpdateEntity 内部对 AllTrackedEntities.ContainsReference() 的调用占用了。
为了给出一些实际数字，根据我最近的一次测试运行:
- SubmitChangesImpl 的时间:204884 毫秒
- UpdateEntity 中的时间:200908 毫秒
- ContainsReference 中的时间:148173 毫秒
- QueryBuilder.GetUpdateQuery 中的时间:685 毫秒
- QueryRunner.Update 中的时间:28 毫秒
- UpdateReferencedObjects 中的时间:49958 毫秒
- UpdateEntity 中的时间:200908 毫秒
如您所见，构建和运行 SQL 查询所花费的时间与检查是否存在对我们正在更新的实体的引用所花费的时间相比相形见绌(如果没有引用，则插入实体，尽管在在这种情况下，所有更新的实体都存在)。虽然我理解为什么会发生这种情况，以保持数据完整性等，但这会降低这些定期更新操作的性能。
我查看了将 ObjectTrackingEnabled 设置为 false，但这使得 DataContext 是只读的，这对我没有用 - 我的问题特别是更新的性能。
有什么可以提高更新性能的方法吗？就尝试在一次提交中推送 40-50 次插入和 80 多次更新而言，我是否以不太理想的方式使用 DbLinq？如果是这样，是否有更好的方法来解决这个问题？
最佳答案
如果您使用长期存在的 DataContext，您可以在其中读取数据、修改数据、提交更改，然后重复使用相同的 DataContext 对象，这会对性能产生负面影响。一旦 DataContext 实现了一个实体，它将在 DataContext 的生命周期内将其保留在内部，作为其对象跟踪的一部分。随着时间的推移，这个内部缓存可能会变大，在某些情况下会有效地成为数据库大部分的内存缓存。这会减慢速度，并导致在 SubmitChanges 期间为 DataContext 做更多的工作。
DataContext 是短暂的。它的生命周期应该是一个工作单元。创建它，将其用于某些用途，然后处置它。
这里有一些更详细的信息:
Why would reusing a DataContext have a negative performance impact?
这是由熟悉产品的人提供的:
Long-lived usage:DataContext does not itself overwrite the objects once you retrieve them through queries. So as time passes, the retrieved objects can become stale if they are frequently changed.
Life after SubmitChanges(): DataContext could be used after SubmitChanges() but one has to be careful. SubmitChanges() does all the hard work of figuring out all the changes you have made to the object graph. It orders the CUD operations for you and provides optimistic concurrency check at the granularity of each changed object.
关于c# - DbLinq 的对象跟踪的性能可以提高吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11107910/