EF架构~linq模拟left join的两种写法,性能差之千里!

简介:

对于SQL左外连接我想没什么可说的,left join将左表数据都获出来,右表数据如果在左表中不存在,结果为NULL,而对于LINQ来说,要实现left join的效果,也是可以的,在进行join时直接into到集合变量就可以了,但在赋值时,如果只需要集合的一条记录,那在写法上又会有两种,而这两种写法所产生的性能是相关千里的,下面来看一下.

首先是SQL的左外连接

SELECT  [t6].[CourseID] ,
        [t6].[UserID] ,
        [t6].[CourseName] ,
        [t6].[ResourceID] ,
        [t6].[StudyTime] ,
        [t6].[BeginTime] ,
        [t6].[EndTime] ,
        [t6].[value] AS [CategoryID] ,
        [t6].[value2] AS [ClassHour] ,
        [t6].[value3] AS [Percent] ,
        [t6].[test] ,
        [t6].[ID] ,
        [t6].[SmallPicture]
FROM    dbo.User_Course AS t6
        LEFT  OUTER JOIN [User_StudyRecord] AS t3 ON t6.UserID = t3.UserID
                                                     AND t3.ResourceID = t6.ResourceID

当它被翻译成LINQ之后,是分页产生的结果,所以感觉更很乱了,呵呵,(LINQ在翻译SQL时,本来就够乱的,再一分页,用上row_number,更乱了),但结果是一样的,

咱们就不管微软是怎么翻译的了

我们重要是看一下,实现时LINQ代码的写法

第一种,性能低下的,如果结果为20条记录,那它需要多连接20次

            var linq = from _data in new User_Course(UnitOfWork).GetEntities()
                       let list = new Res_Item(UnitOfWork).GetEntities().Select(t => new Entity.Res_Item
                       {
                           ID = t.ID,
                           SmallPicture = t.SmallPicture,
                       }).Where(i => i.ID == _data.ResourceID)
           
                       let list2 = new User_StudyRecord(UnitOfWork).GetModel().Select(r => new Entity.User_StudyRecord
                       {
                           StudyContent = r.StudyContent,
                           UserID = r.UserID,
                           Res_ItemID = r.Res_ItemID,
                       }).Where(i => i.Res_ItemID == _data.ResourceID && i.UserID == _data.UserID)
                       from record in list2.DefaultIfEmpty()
                       where _data.CategoryID != (int)CustomEnum.CategoryType.BroadcastProgram
                       && _data.CategoryID != (int)CustomEnum.CategoryType.AskRoom
                       select new Entity.User_Course
                       {
                           CourseID = _data.CourseID,
                           UserID = _data.UserID,
                           CourseName = _data.CourseName,
                           ResourceID = _data.ResourceID,
                           StudyTime = _data.StudyTime,
                           BeginTime = _data.BeginTime,
                           EndTime = _data.EndTime,
                           CategoryID = _data.CategoryID ?? 2,
                           Res_Item = list.FirstOrDefault(),
                           ClassHour = _data.ClassHour ?? 0,
                           Percent = _data.Percent ?? 0,
                           Prev_ResourceName = record == null ? string.Empty : record.StudyContent,
                       };

第二种,性能较好的

总结:对于第一种性能较差的写法产生的结果,类似于LINQ本身提交的延时加载,即结果集中,每条记录都去查询数据库,它不会一次将数据获出来,这种作用在特定场合是

有它的好处的,但不适用于所有,当返回结果集比较大时,不应该使用延时加载!

本文转自博客园张占岭(仓储大叔)的博客,原文链接:EF架构~linq模拟left join的两种写法,性能差之千里!,如需转载请自行联系原博主。

目录
相关文章
|
2月前
|
存储 调度 C++
16 倍性能提升,成本降低 98%! 解读 SLS 向量索引架构升级改造
大规模数据如何进行语义检索? 当前 SLS 已经支持一站式的语义检索功能,能够用于 RAG、Memory、语义聚类、多模态数据等各种场景的应用。本文分享了 SLS 在语义检索功能上,对模型推理和部署、构建流水线等流程的优化,最终带给用户更高性能和更低成本的针对大规模数据的语义索引功能。
268 15
|
4月前
|
存储 数据挖掘 BI
2-5 倍性能提升,30% 成本降低,阿里云 SelectDB 存算分离架构助力波司登集团实现降本增效
波司登集团升级大数据架构,采用阿里云数据库 SelectDB 版,实现资源隔离与弹性扩缩容,查询性能提升 2-5 倍,总体成本降低 30% 以上,效率提升 30%,助力销售旺季高效运营。
308 9
|
6月前
|
人工智能 API 数据安全/隐私保护
Apifox 与 Apipost 的 API 文档引擎对比:底层架构、性能与可扩展性分析
深入探索市场上两大主流API工具——Apifox和Apipost的文档能力时,发现了令人惊讶的差距。这不仅仅是功能多寡的问题,更关乎开发效率与团队协作的质变。
|
7月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
9月前
|
SQL 缓存 分布式计算
vivo 湖仓架构的性能提升之旅
聚焦 vivo 大数据多维分析面临的挑战、StarRocks 落地方案及应用收益。 在 **即席分析** 场景,StarRocks 使用占比达 70%,查询速度提升 3 倍,P50 耗时从 63.77 秒缩短至 22.30 秒,查询成功率接近 98%。 在 **敏捷 BI** 领域,StarRocks 已完成 25% 切换,月均查询成功数超 25 万,P90 查询时长缩短至 5 秒,相比 Presto 提升 75%。 在 **研发工具平台** 方面,StarRocks 支持准实时数据查询,数据可见性缩短至 3 分钟,查询加速使 P95 延迟降至 400 毫秒,开发效率提升 30%。
vivo 湖仓架构的性能提升之旅
|
3月前
|
存储 JSON 数据处理
ClkLog埋点与用户行为分析系统:架构升级与性能全面提升
随着越来越多企业在实际业务中使用 ClkLog,数据规模和分析需求也不断提升,部分用户日活已经超过10万,为了顺应这一趋势,ClkLog 秉持 “开放透明、持续演进”的理念,推出了迄今为止最重要的一次性能优化升级。新版本在大规模数据处理与复杂查询场景中,性能表现实现了跨越式提升。经过多轮研发与严格测试,新版本现已正式上线:在原有付费版 1.0 的基础上架构全面升级,并同步发布全新的 2.0 版本。为用户带来更强的性能与更广的适用场景。
|
6月前
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
|
6月前
|
存储 缓存 分布式计算
高内存场景必读!阿里云r7/r9i/r8y/r8i实例架构、性能、价格多维度对比
阿里云针对高性能需求场景,一般会在活动中推出内存型r7、内存型r9i、内存型r8y和内存型r8i这几款内存型实例规格的云服务器。相比于活动内的经济型e和通用算力型u1等实例规格,这些内存型实例在性能上更为强劲,尤其适合对内存和计算能力有较高要求的应用场景。这些实例规格的云服务器在处理器与内存的配比上大多为1:8,但它们在处理器架构、存储性能、网络能力以及安全特性等方面各有千秋,因此适用场景也各不相同。本文将为大家详细介绍内存型r7、r9i、r8y、r8i实例的性能、适用场景的区别以及选择参考。

热门文章

最新文章