EF 延时加载与死锁
程序员文章站
2022-05-11 12:53:36
第一种 第二种 怎么看生成的sql语句的? 1)数据库里 致博客园 1)傻逼的150字数限制! 2)范围竟然不包括代码! 3)添加成功修改失败,似乎对修改很有意见! 致博客园 1)傻逼的150字数限制! 2)范围竟然不包括代码! 3)添加成功修改失败,似乎对修改很有意见! 致博客园 1)傻逼的150 ......
第一种
#region 第一种延迟加载 用到的时候就会去查询数据。 //用到的时候就会去查询数据。 //IQueryable<UserInfo> temp = from u in dbContext.UserInfo // //where u.UName.Contains("o") // //&& u.UName.StartsWith("D") // select u; //测试一 //foreach (var userInfo in temp) //{ // Console.WriteLine(userInfo.ID + " " +userInfo.UName); //} //foreach (var userInfo in temp) //{ // Console.WriteLine(userInfo.ID + " " + userInfo.UName); //} //数据库监视发现:查询了两次。 //因为IQueryable每次用到时都会重新查询,所以查询到的数据不可作为缓存。
//测试二: linq的重用,在temp的基础上继续查询得temp2 //var temp2 = from u in temp // where u.ID > 0 // select u; //foreach (var userInfo in temp2) //{ // Console.WriteLine(userInfo.ID + " " + userInfo.UName); //} //数据库监视发现 temp和temp2一共只查询了一次,两次linq查询只生成了一条sql语句。 相当于原生ADO时期的sql脚本拼接。 #endregion
第二种
#region 第二种延迟加载
//IQueryable<UserInfo> temp = from u in dbContext.UserInfo // //where u.UName.Contains("o") // //&& u.UName.StartsWith("D") // select u;
//单表多次查询
//foreach (var userInfo in temp) 交互1次
//{ // foreach (var orderInfo in userInfo.OrderInfo) 交互 100次 // { // Console.WriteLine(userInfo.UName+ " " +orderInfo.ID + " " + orderInfo.Content); // } //}
//多表一次连接查询 Include("OrderInfo")
//IQueryable<UserInfo> temp = from u in dbContext.UserInfo.Include("OrderInfo") // //where u.UName.Contains("o") // //&& u.UName.StartsWith("D") // select u;
//情景1:当数据量小的时候(一般不会再页面展示所有数据,而是分页,数据量不会特别大,那么必须减少连接数据库的次数)
//若采用单表查询,若查询100个用户数据,共需与数据库交互101=1+100,交互的时间就比一次"连接查询"时间还要长。
//所以数据量较少时直接使用连接查询比价高效。
//情景2:当数据量特别大时。例如: 用户表跟订单表数据都是10000 0000条 //若采用一次连接查询:根据笛卡尔积,数据库过滤数据实际条数是10000 0000 * 10000 0000
//很可能会使数据库崩溃。 //若采单表多次查询,内存中重组数据。可以很好的解决以上问题。
//问题来了: //并发访问 多次查询,若出现并发访问怎么办? //理解并发: //在操作系统中,并发是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行,但任一个时刻点上只有一个程序在处理机上运行。 //在关系数据库中,允许多个用户同时访问和更改共享数据的进程。SQL Server 使用锁定以允许多个用户同时访问和更改共享数据而彼此之间不发生冲突。 //在这里访问由于锁的存在,并发问题转换成了计算能力问题,计算能力可以通过添加服务器来讲解决。 //3死锁问题: //理解死锁 //死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。 //出现情况 // 表连接查询出现: 进程X占用A表,X想连接B表,必须等B表释放; 但同时y又占用了B表,y想有连接了A表,在等A表释放。 结果x、y都在等待,二A、B表同时被占用着。 // 连接的表越多,死锁问题越突出。 //解决方案: 临时表 //为什么能解决?因为此时锁定的是临时表,而原始表处于释放状态。 //临时表有两种类型:本地表和全局表。在与首次创建或引用表时相同的 SQL Server 实例连接期间,本地临时表只对于创建者是可见的。当用户与 SQL Server 实例断开连接后,将删除本地临时表。全局临时表在创建后对任何用户和任何连接都是可见的,当引用该表的所有用户都与 SQL Server 实例断开连接后,将删除全局临时表。 //详情可百度临时表用法 #endregion
怎么看生成的sql语句的?
1)数据库里
详情可百度: SQL Server Profiler (事件追踪)
2)断点调试时
查询数据后,快速监视如下。查询数据前是没有这些内容的。
致博客园
1)傻逼的150字数限制!
2)范围竟然不包括代码!
3)添加成功修改失败,似乎对修改很有意见!
致网友:如有错误,望立刻指正。
上一篇: 物联网愿景的另一面:互联网日益隔离化
下一篇: 高校开新专业 江苏6校争开物联网专业