给 EF Core 查询增加 With NoLock Intro EF Core 在 3.x 版本中增加了 Interceptor,使得我们可以在发生低级别数据库操作时作为 EF Core 正常运行的一部分自动调用它们. 例如,打开连接.提交事务或执行命令时. 所以我们可以自定义一个 Interceptor 来记录执行的 sql 语句,也可以通过 Interceptor 来实现 sql 语句的执行. 这里我们可以借助 Interceptor 实现对于查询语句的修改,自动给查询语句加 (WITH

1.出错结果:数据库表视图有多条数据,在使用EF框架进行查询时却只得到一条数据(注:拦截EF得到的sql语句在数据库进行查询并没有任务问题). 2.出错原因:该视图中没有ID或者主键,EF查询时进行反射默认都是同一条数据. 3.总结:EF框架查询视图时需要注意加入ID或者主键 以上仅是个人简单分析.

我们做项目时,难免会遇到用的不知道是啥,及把linq和EF搞混了 今天我带领大家梳理下思路: 首先说linq查询,然后介绍EF查询 1.linq查询 当我们使用linq查询时,转到定义会调到Queryable 类,  那么也就是说,这个类封装了linq所有查询的方法,那么我们来研究研究这个类 MSDN上是这样解释的:提供一组用于查询实现 IQueryable<T> 的数据结构的 static(在 Visual Basic 中为 Shared)方法. 命名空间:   System.Linq程序集

在EF 4和EF 3.5 SP1中,我们可以使用ToTraceString()方法得到EF查询所生成的SQL. using (var context = new TestDBEntities()) { var query = from p in context.Parents where p.Name == "zhaokun" select p; ObjectQuery<Parent> parents = query as ObjectQuery<Parent>

一个简单的EF查询框架除了运行项目外,大概需要5个类库项目,当然这个不是一定要这样做,这可以根据自己的需要设置有多少个项目.这里介绍的方法步骤只适合EF零基础的人看看就是了. 在开始之前,先建立一个运行项目,不管是MVC还是winfrom项目,只要能运行就OK,这是为了在后面能测试EF框架的地方. 一.模型项目.这个项目主要负责与数据库映射的,里面的类都是数据库表的实体. 首先在解决方案中建一个文件夹EFModel,这里将会收纳所有的与EF查询有关的项目,这样做只是为了将他们与运行项目分开而已,

相关文章:EF查询百万级数据的性能测试--单表查询 一.起因  上次做的是EF百万级数据的单表查询,总结了一下,在200w以下的数据量的情况(Sql Server 2012),EF是可以使用,但是由于查询条件过于简单,且是单表查询,EF只是负责生成Sql语句,对于一些简单的查询,生成Sql语句的时间可以基本忽略,所以不仅没有发挥出EF的优势,而且这样的性能瓶颈基本可以说是和数据库完全有关的,这个锅数据库得背(数据库:怪我了).鉴于实际项目中多是多表的连接查询,还有其他复杂的查询,一向本着求真务实

解决方案: 由多张表组成的视图,要加实体键.而且实体键组合要能确保唯一性. 个人理解:确保唯一性,一个或多个实体键,实现了复合主键或组合主键的效果. 这样查询是,延迟加载机制,才知道哪些需要重新从数据库中拿而不是缓存中. 在思考:实体键的字段可以不是某个表的主键!?只要能确保唯一性行,其实“实体键的组合”也相当于“唯一索引”了. 总结:在模型中,加一个或多个实体键,只要能确保唯一性就行. 相关文章: EF 查询视图返回重复数据的问题 http://www.mamicode.com/info-de

一.查询的工作原理 Entity Framework Core 使用语言集成查询 (LINQ) 来查询数据库中的数据. 通过 LINQ 可使用 C#(或你选择的其他 .NET 语言)基于派生上下文和实体类编写强类型查询. LINQ 查询的表示形式会传递给数据库提供程序,进而转换为特定的数据库查询语言(例如,适用于关系数据库的 SQL). 1.1 查询的生命周期, 下面是每个查询所经历的过程概述: (1) LINQ 查询由 E F处理,用于生成已准备好的表示形式,由数据库提供程序处理.缓存结果,以

1.SQL Server查询中WITH(NOLOCK) SELECT语句中加上WITH(NOLOCK)为解决阻塞死锁. 处理数据库死锁异常查询的一种方式是使用NOLOCK 或 READPAST. ◊ NOLOCK:可能显示没有提交事务的数据 ◊ READPAST:不显示被事务锁住数据 1.1 没有提交的事务,NOLOCK 和 READPAST处理的策略 CREATE TABLE [dbo].[Role]( ,) NOT NULL, ) NOT NULL, CONSTRAINT [PK_Role]

EF查询(不使用缓存):Set<T>().AsNoTracking() 今天工作中发现一个很妖的问题,修改产品界面,修改数据后,数据库的值发生变化,感觉掉坑里了. 然后发现读取对象的方法是这样写的: public T GetModel(object id) { return dbContext.Set<T>().Find(id); } 后来发现原来是读的EF缓存的数据,然后将读取方法改成: public T GetModel(Expression<Func<T, boo

EF 查询外键对应的实例   1. 查询时易遇到的情况: 能查询到外键值,但对应的外键实例为null. 解决方法: (1) 使用EF的include // 我的应用如下 // SampleResult中的Sample为外键对应的实例. // Test为Sample中对应的实例 public void Search() { DateTime tMin = _minDateTime == null ? DateTime.MinValue : _minDateTime.Value.Date; Date

上一篇:EF使用CodeFirst方式生成数据库&技巧经验 前言 EF相信大部分同学都已经经常使用了,可是你的查询高效吗? 今天我就以个人使用经验来讲讲在使用EF做查询的时候大家都容易忽略的性能提升点. 本文将继续接着上一篇(EF使用CodeFirst方式生成数据库&技巧经验)来写 数据准备 public ActionResult Index() { using (var db = new Core.EF.MyDbContext()) { //添加测试数据 ; i < ; i++)

使用mvc ef更新后数据之后刷新页面,发现页面的数据没有变,而数据库的数据更新了,找了一点资料,是因为ef6有个缓存机制: Repository 类: //此方法查询结果有缓存 public List<T> FindAll() { return context.Set<T>().ToList(); } ///去掉次缓存 public List<T> FindAll() { return context.Set<T>().AsNoTracking().ToL

当我们在操作数据库的时候,无论是查询还是修改数据库的操作我们都习惯使用using(var db=new XXXDB()){},但是如果仅仅是做查询,最好是使用NoLock,因为NoLock使用的是共享锁,可以减少死锁发生的机率.

现象:前台grid发送ajax请求,通过谷歌devtool发现“waiting”时间高达23s(1500条数据);可见服务器端代码处理花费时间很长: 解决:分析代码,有两处代码注释掉后速度提升明显 //第一处,查询所有考试成绩:1500条 var data = _scoreResultService.GetAllKenScoreResults().ToList(); //去掉ToList()后查询时间减少明显(3s); //第二处; foreach (var item in data) { Ke

一天做项目的时候遇到这样的问题,MVC4用EF访问数据查询用linq语句的时候报错找不到表名:报错如下图: 研究了几种情况,最后还是没有找到正真的问题所在,不过可能是和路由解析问题有关,暂时还没有进行这个研究,但是目前这个问题是有解决办法的,方法如下: 1.有下划线的表名和实体类名是相同的可以找到表名 2.没有下划线的表名和实体类名不相同的可以找到表名

原文:http://blog.csdn.net/eqera/article/details/8411437 这是这了系列的最后一篇,我将讨论如何绕过 EF 的查询映射. 像所有优秀的框架一样,EF 知道它并不能优秀到覆盖所有的角落,通过允许直接访问数据库,EF 支持开放底层的 ADO.NET 框架. 有三个 API 支持: DbContext.Database.ExecuteSqlCommand DbContext.Database.SqlQuery DbSet.SqlQuery 第一个没有什么

一.起因  个人还是比较喜欢EF的,毕竟不用写Sql,开发效率高,操作简单,不过总是听人说EF的性能不是很好,也看过别人做的测试,但是看了就以为真的是那样.但是实际上到底是怎么样,说实话我真的不知道.我只知道选什么的框架是基于实际情况的,博主在一个创业公司上班,选的就是EF框架,刚做了一个项目,数据也就几万不到,感觉性能没那么差劲.于是,就想多弄点数据测试一下.再说一遍,本着 求真务实的方针,是针对现实中的业务需求来测试的,不是来单比性能的.你要是做个ERP系统,都去考虑千万级并发的架构,那当我

一. 原生SQL查询 接着上篇讲.通过 Entity Framework Core 可以在使用关系数据库时下降到原始 SQL 查询. 在无法使用 LINQ 表达要执行的查询时,或因使用 LINQ 查询而导致低效的 SQL 查询时非常有用. 原始 SQL 查询可返回实体类型,或者从 EF Core 2.1 开始,可返回模型中的查询类型. 1.1 基本的原始SQL查询 可以使用FromSql扩展方法,基于原始的SQL查询,开始LINQ查询. var blogs = context.Blogs .Fr

using (SchoolContext dbCOntext = new SchoolContext()) { string str = "select * from student"; System.Data.Common.DbCommand cmd = dbCOntext.Database.Connection.CreateCommand(); cmd.CommandText = str; cmd.CommandType = CommandType.Text; //转成sqlcom

第一个问题 var res = pwDb.Set<WorkInfo>().Where(t => t.WorkTime > startTime && t.WorkTime < endTime); 用大余小余就行了,简单. 第二个问题就麻烦了,数据库内储存的时间是含有秒.而js传过去时间只有日期,而我们实际操作时,也只需要查询日期.这个时候EF会自动把日期时间加上00:00:00,这样前端选择最后一天就查不到,应该是23:59:59才对. 解决办法: endTim