.net – 针对SQL等效的LINQ查询的性能
发布时间：2020-12-12 06:21:40 所属栏目：MsSql教程 来源：网络整理
导读：我目前正在和一个正在讨论SQLQ等效LINQ查询性能的人进行辩论. 有没有人对此进行过任何科学测试？ 如果没有,由于性能原因你必须用SQL查询替换LINQ的轶事证据将帮助我说明问题. 解决方法 我对此略有不同;在进行性能分析时(使用我们的 shiny profiler),我们注意
|
我目前正在和一个正在讨论SQLQ等效LINQ查询性能的人进行辩论.
有没有人对此进行过任何科学测试？ 如果没有,由于性能原因你必须用SQL查询替换LINQ的轶事证据将帮助我说明问题. 解决方法我对此略有不同;在进行性能分析时(使用我们的 shiny profiler),我们注意到LINQ(在本例中为SQL)正在为基本查询生成TSQL,并且操作在DB服务器上运行得非常快(0.5ms等) – 但实际上查询操作花费的时间更长(对于相同的0.5ms查询,在某些情况下为20ms).那么时间到了哪儿？您可能会想到“查询翻译”,但没有;我们还有很多ExecuteQuery< T>代码(即你手工编写TSQL的地方),这是完全相同的事情.事实证明,在物化者和身份地图之间的某个地方,大量的时间正在流失.所以;我们编写了自己的物化器,它实际上是ExecuteQuery的替代品 – 因此诞生于dapper. 在更多的LINQ方面,它通常可以为简单查询生成TSQL,但对于任何复杂的东西,我通常更信任手工编码的TSQL.以案例为样本,我有一个涉及组,跳过和接受的复杂查询.它表现不佳.当我用ROW_NUMBER()等手写它时,相同的结果占了“统计IO”和总时间的4％. 我目前对LINQ的看法是,ORM工具使数据变异变得轻而易举,但对于查询,我倾向于使用dapper.这是具有讽刺意味的,因为LINQ中的Q是“查询”. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |