C# MVC迷你探查器-LINQ开销

我正在使用MVC Mini Profiler，并试图测量查询的LINQ到SQL部分（生成表达式树、实际的SQL命令等）与在数据库端花费的时间之间的影响

我看到“此步骤中所有查询的聚合持续时间（不包括子项）”。这包括LINQ到SQL部分和数据库调用，还是只包括数据库部分？当单击“sql”链接查看已运行查询的列表时，我会看到一个查询持续时间。同样，这包括LINQ部分还是仅包括数据库端

---

谢谢。

SQL计时是仅仅是SQL-因为它来自包装好的ADO.NET连接，对调用方知之甚少。要获得详细的时间安排（测量开销），请包装您感兴趣的代码：

using(profiler.Step("Get orders")) {
    orders = db.{some query}.ToList();
}

现在，您有了代码单元的计时，在该计时中，有了与之对应的SQL计时。因此，如果“获取订单”代码需要100毫秒，SQL代码需要40毫秒，那么就需要60毫秒的开销

减少开销的措施：

• 尝试预编译查询
• 尝试切换到

  ExecuteQuery

  ，这样就没有要解析的表达式树了

---

但是，根据经验，您可能会发现这些开销中的大多数来自“物化”（即将数据库中的行转换为对象），特别是在高吞吐量场景中。我们发现，摆脱这种开销的唯一方法是使用dapper dot net来替代

ExecuteQuery

（它有一个故意类似的API）。这样，在“获取订单”的计时和该块中SQL的计时之间，我们几乎没有开销。

谢谢Marc。是的，在一个特定的页面上，我有9个sql查询，总共大约5ms，呈现逻辑大约5.5ms，其余的是165ms的LINQ2SQL开销；在我看来，这是不可接受的。我考虑过ExecuteQuery/Dapper/Massive/等等。所有这些的问题是，我需要回到字符串SQL。从我发现的最快的图书馆，仍然允许我留在林克兰似乎是BLToolkit。我需要进一步研究。@pbz您可能需要先尝试预编译查询；这将删除表达式树解析步骤等，但仍然会有物化开销。如果可能的话，您也可以尝试禁用更改跟踪和标识管理器。我将运行一些测试，看看编译后的查询是否有显著差异（禁用跟踪）。谢谢。@pbz设定期望值：对我们来说，这有帮助，但不是重要的部分。这就是为什么我们离开了，写了一篇短小精悍的文章；p当然值得一试，但是，对于许多查询，您都有最准确的数字fwiw。在我的测试中，开销如下：Dapper为0.32ms，BLToolkit为0.47ms，编译的LINQ2SQL为1ms（惊喜），非编译的LINQ2SQL为12.6ms。数据库查询平均耗时1.6ms。我确保所有3个生成的SQL查询都相同。