Linq to Sql中Single写法不当可能引起的数据库查询性能低下

简介: 场景:需要从T_User表中返回指字条件的某条记录的某一个字段 在Linq中有二种理论上都行得通的写法,见下面的代码: Codeusing (dbUserDataContext db = new dbUserDataContext(Website.

场景:需要从T_User表中返回指字条件的某条记录的某一个字段

在Linq中有二种理论上都行得通的写法,见下面的代码:

img_1c53668bcee393edac0d7b3b3daff1ae.gif img_405b18b4b6584ae338e0f6ecaf736533.gif Code
using (dbUserDataContext db = new dbUserDataContext(Website.ConnStrdbUser))
            {
                
try { 
                    
//Guid _UserId = db.T_User.Single(c=>c.F_ID==new Guid("00000000-0000-0000-0000-000000000001")).F_ID;
                    
//最终提交到数据库的语句是
//                    exec sp_executesql N'SELECT [t0].[F_ID], [t0].[F_No], [t0].[F_NickName], [t0].[F_Title], [t0].[F_Sex], [t0].[F_Birthday], ...FROM [dbo].[T_User] AS [t0] WHERE [t0].[F_ID] = @p0',N'@p0 uniqueidentifier',@p0='00000000-0000-0000-0000-000000000001'
                    
//即先把整条记录的所有字段全部取出,转化成T_User对象后,再将T_User.F_ID赋值给_UserId

                    Guid _UserId 
= db.T_User.Where(c => c.F_ID == new Guid("00000000-0000-0000-0000-000000000001")).Select(c => c.F_ID).Single();
                    
//最终提交到数据库的语句是
//                    exec sp_executesql N'SELECT [t0].[F_ID]
//FROM [dbo].[T_User] AS [t0]
//WHERE [t0].[F_ID] = @p0',N'@p0 uniqueidentifier',@p0='00000000-0000-0000-0000-000000000001'
                    
//这才是我们想要的语句,即仅查询一个字段
                }
                
catch { }
                
finally { db.Connection.Close();//这一行纯属个人习惯,不必强求 }

 

初看上去
Guid _UserId = db.T_User.Single(c=>c.F_ID==new Guid("00000000-0000-0000-0000-000000000001")).F_ID;
这种写法似乎要比下面的写法省事得多
Guid _UserId = db.T_User.Where(c => c.F_ID == new Guid("00000000-0000-0000-0000-000000000001")).Select(c => c.F_ID).Single();
但观察最终提交到sqlserver的语句发现,第一种写法生成的语句返回了大量我们并不需要的字段,其实理解起来,也应该是这样的,先Single出一个对象后,再取其中一个属性,可不就是这样么!

前几天,看到园子里有N多人说Linq如何如何差,甚至说linq要淘汰之类,感到很滑稽,技术本身并无问题,看你怎么用了,vb也能弄出很不错的系统,就象本文所提的内容,对linq有成见的人,可能会说:"linq真烂,这么不智能,很傻很天真";而真正用linq的人,也许会说:"原来如此,以后我们应该用正确的写法,以避免因疏忽导致的性能问题"--生活很美好,快乐自己找,关键在于用什么角度去看,呵呵

目录
打赏
0
0
0
0
38
分享
相关文章
如何用 esProc 将数据库表转储提速查询
当数据库查询因数据量大或繁忙变慢时,可借助 esProc 将数据导出为文件进行计算,大幅提升性能。以 MySQL 的 3000 万行订单数据为例,两个典型查询分别耗时 17.69s 和 63.22s。使用 esProc 转储为二进制行存文件 (btx) 或列存文件 (ctx),结合游标过滤与并行计算,性能显著提升。例如,ctx 并行计算将原查询时间缩短至 0.566s,TopN 运算提速达 30 倍。esProc 的简洁语法和高效文件格式,特别适合历史数据的复杂分析场景。
【YashanDB知识库】字段加上索引后,SQL查询不到结果
【YashanDB知识库】字段加上索引后,SQL查询不到结果
OmniSQL:开源文本到SQL神器!自然语言秒转查询到复杂多表连接等SQL需求
OmniSQL是开源的文本到SQL转换模型,通过创新的数据合成框架生成250万条高质量样本,支持7B/14B/32B三种模型版本,能处理从简单查询到复杂多表连接等各种SQL需求。
168 16
OmniSQL:开源文本到SQL神器!自然语言秒转查询到复杂多表连接等SQL需求
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL 数据库 SQL 语句调优方法详解(2-1)
本文深入介绍 MySQL 数据库 SQL 语句调优方法。涵盖分析查询执行计划,如使用 EXPLAIN 命令及理解关键指标;优化查询语句结构,包括避免子查询、减少函数使用、合理用索引列及避免 “OR”。还介绍了索引类型知识,如 B 树索引、哈希索引等。结合与 MySQL 数据库课程设计相关文章,强调 SQL 语句调优重要性。为提升数据库性能提供实用方法,适合数据库管理员和开发人员。
数据库编程:在PHP环境下使用SQL Server的方法。
看看你吧,就像一个调皮的小丑鱼在一片广阔的数据库海洋中游弋,一路上吞下大小数据如同海中的珍珠。不管有多少难关,只要记住这个流程,剩下的就只是探索未知的乐趣,沉浸在这个充满挑战的数据库海洋中。
55 16
玩转大数据:从零开始掌握SQL查询基础
玩转大数据:从零开始掌握SQL查询基础
139 35
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
【YashanDB知识库】python驱动查询gbk字符集崖山数据库CLOB字段,数据被驱动截断
【YashanDB知识库】python驱动查询gbk字符集崖山数据库CLOB字段,数据被驱动截断
【YashanDB知识库】数据库用户所拥有的权限查询
【YashanDB知识库】数据库用户所拥有的权限查询
百万指标,秒级查询,零宕机——时序数据库 TDengine 在 AIOps 中的硬核实战
本篇文章详细讲述了七云团队在运维平台中如何利用 TDengine 解决海量时序数据存储与查询的实际业务需求。内容涵盖了从数据库选型、方案落地到业务挑战及解决办法的完整过程,特别是分享了升级 TDengine 3.x 时的实战经验,给到有需要的小伙伴参考阅读。
68 1

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等