我正在使用最新的 ASP.NET MVC 和实体框架（MVC 5.2.2、EF 6.1.2）和最新的 Glimpse。我正在努力改进查询时间，以急切地加载具有多个嵌套子对象的实体，并通过使用 .Include("Object.Child") 引入导航属性来减少查询数量。起初，我以为我得到了一个很好的结果，看到 Glimpse 的 SQL 选项卡中的“总查询执行时间”显着减少。然而，“总连接打开时间”仍然很高，并且对于由此产生的组合大型查询来说非常长。请看下面的截图。
我想知道是否有人可以帮助我了解这两个持续时间的差异是怎么回事？ Glimpse 说我的命令需要 5 秒。在这种情况下，查询确实很混乱，有很多连接等，但是如果查询本身确实在 100 毫秒内完成，则不清楚时间在哪里。
注意：我在这里看到了关于why two durations 的答案，但它并没有解释每个的性质。
【问题讨论】：
标签： asp.net-mvc entity-framework glimpse
感谢您提出问题。连接持续时间的计时器在连接打开时开始，在连接关闭时结束。为了进一步解决这个问题，您如何使用您的上下文/连接，您是否共享它、保留它等等？
【讨论】：
经过进一步测试，我想我已经弄清楚发生了什么。我在另一个问题中看到，它表明 .Include() 方法在 Entity Framework 中急切加载分层实体可能会导致复杂查询，结果集中有许多连接和重复数据。我有一个很长的 XML 字符串作为我的属性之一，所以如果这在数据库中重复多次，返回/处理将需要很长时间。
作为测试，我清除了数据密集型字段并重新运行查询，获得了更短的“连接”持续时间（Glimpse 中右侧的一个列表）。总共从 9 秒缩短到 200 毫秒以下。基于此，我假设数据大小是罪魁祸首，并吸取了我以这种方式使用大数据属性的教训。
我仍然很想知道 Glimpse 是否可以向您显示查询返回的原始数据，甚至显示以字节为单位的大小以及记录数。这可能会使这个问题变得明显。
【讨论】：
这个问题有点晚了，但我遇到了同样的问题，也试图了解我的查询执行时间和连接打开时间之间的差异。
FWIW，我发现我将视图模型中的枚举传递给视图，而不是具体列表。因此，视图触发了对查询的评估并延长了连接保持打开的时间。通过传递项目列表（在可枚举对象上调用 .ToList()），我大大减少了连接保持打开的时间。
【讨论】：