[转]Linq to Sql中Single写法不当可能引起的数据库查询性能低下
2009-10-10 10:38
651 查看
场景:需要从T_User表中返回指字条件的某条记录的某一个字段
在Linq中有二种理论上都行得通的写法,见下面的代码:
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的人,也许会说:"原来如此,以后我们应该用正确的写法,以避免因疏忽导致的性能问题"--生活很美好,快乐自己找,关键在于用什么角度去看,呵呵
在Linq中有二种理论上都行得通的写法,见下面的代码:
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的人,也许会说:"原来如此,以后我们应该用正确的写法,以避免因疏忽导致的性能问题"--生活很美好,快乐自己找,关键在于用什么角度去看,呵呵
相关文章推荐
- Linq to Sql中Single写法不当可能引起的数据库查询性能低下
- 性能,使用Linq to sql 一个可能导致内存溢出的写法
- ScottGu之博客翻译-LINQ to SQL第三部分,查询数据库 (Part 3 - Querying our Database)
- 是否会成为问题——Linq to Sql的执行可能无法复用查询计划
- LINQ to SQL 查询数据库和使用存储过程
- Linq to Sql: 集成数据库语言查询之一
- 1.4.3 LINQ to SQL 对数据库应用查询表达式
- LINQ to SQL的执行可能无法复用查询计划
- Visual C# 2008+SQL Server 2005 数据库与网络开发--11.3.3 LINQ to SQL的数据库查询
- LINQ to SQL 查询数据库和使用存储过程
- Linq to Sql: 集成数据库语言查询之二
- LINQ to SQL 查询数据库和使用存储过程
- AdoNet vs LinqToSql vs NIntegrateQuery查询性能测试
- LINQ – 使用DataLoadOptions 提高LINQ to SQL 查询性能
- Linq to sql 中解析成in查询写法
- AdoNet vs LinqToSql vs NIntegrateQuery查询性能测试
- (翻译) LINQ to SQL (Part 3 - 查询数据库)
- 是否会成为问题——Linq to Sql的执行可能无法复用查询计划
- Linq to SQL查询数据库
- 是否会成为问题——Linq to Sql的执行可能无法复用查询计划