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的人,也许会说:"原来如此,以后我们应该用正确的写法,以避免因疏忽导致的性能问题"--生活很美好,快乐自己找,关键在于用什么角度去看,呵呵

目录
相关文章
|
14天前
|
SQL Oracle 数据库
使用访问指导(SQL Access Advisor)优化数据库业务负载
本文介绍了Oracle的SQL访问指导(SQL Access Advisor)的应用场景及其使用方法。访问指导通过分析给定的工作负载,提供索引、物化视图和分区等方面的优化建议,帮助DBA提升数据库性能。具体步骤包括创建访问指导任务、创建工作负载、连接工作负载至访问指导、设置任务参数、运行访问指导、查看和应用优化建议。访问指导不仅针对单条SQL语句,还能综合考虑多条SQL语句的优化效果,为DBA提供全面的决策支持。
44 11
|
29天前
|
存储 缓存 网络协议
数据库执行查询请求的过程?
客户端发起TCP连接请求,服务端通过连接器验证主机信息、用户名及密码,验证通过后创建专用进程处理交互。服务端进程缓存以减少创建和销毁线程的开销。后续步骤包括缓存查询(8.0版后移除)、语法解析、查询优化及存储引擎调用,最终返回查询结果。
29 6
|
28天前
|
SQL 关系型数据库 MySQL
MySQL导入.sql文件后数据库乱码问题
本文分析了导入.sql文件后数据库备注出现乱码的原因,包括字符集不匹配、备注内容编码问题及MySQL版本或配置问题,并提供了详细的解决步骤,如检查和统一字符集设置、修改客户端连接方式、检查MySQL配置等,确保导入过程顺利。
|
27天前
|
SQL 监控 安全
SQL Servers审核提高数据库安全性
SQL Server审核是一种追踪和审查SQL Server上所有活动的机制,旨在检测潜在威胁和漏洞,监控服务器设置的更改。审核日志记录安全问题和数据泄露的详细信息,帮助管理员追踪数据库中的特定活动,确保数据安全和合规性。SQL Server审核分为服务器级和数据库级,涵盖登录、配置变更和数据操作等事件。审核工具如EventLog Analyzer提供实时监控和即时告警,帮助快速响应安全事件。
|
2月前
|
SQL 关系型数据库 MySQL
体验使用DAS实现数据库SQL优化,完成任务可得羊羔绒加厚坐垫!
本实验介绍如何通过数据库自治服务DAS对RDS MySQL高可用实例进行SQL优化,包含购买RDS实例并创建数据库、数据导入、生成并优化慢SQL、执行优化后的SQL语句等实验步骤。完成任务,即可领取羊羔绒加厚坐垫,限量500个,先到先得。
170 12
|
2月前
|
SQL 存储 BI
gbase 8a 数据库 SQL合并类优化——不同数据统计周期合并为一条SQL语句
gbase 8a 数据库 SQL合并类优化——不同数据统计周期合并为一条SQL语句
|
2月前
|
SQL 数据库
gbase 8a 数据库 SQL优化案例-关联顺序优化
gbase 8a 数据库 SQL优化案例-关联顺序优化
|
2月前
|
SQL 存储 Linux
从配置源到数据库初始化一步步教你在CentOS 7.9上安装SQL Server 2019
【11月更文挑战第16天】本文介绍了在 CentOS 7.9 上安装 SQL Server 2019 的详细步骤,包括配置系统源、安装 SQL Server 2019 软件包以及数据库初始化,确保 SQL Server 正常运行。
|
2月前
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
75 3
|
2月前
|
SQL IDE 数据库连接
IntelliJ IDEA处理大文件SQL:性能优势解析
在数据库开发和管理工作中,执行大型SQL文件是一个常见的任务。传统的数据库管理工具如Navicat在处理大型SQL文件时可能会遇到性能瓶颈。而IntelliJ IDEA,作为一个强大的集成开发环境,提供了一些高级功能,使其在执行大文件SQL时表现出色。本文将探讨IntelliJ IDEA在处理大文件SQL时的性能优势,并与Navicat进行比较。
35 4