我们看到EF正常情况生成的sql会在前面带上“N”，如果我们加上DbFunctions.AsNonUnicode生成的sql是没有“N”的，当你发现带上“N”的sql比没有带“N”的 sql查询速度慢很多的时候那就知道该怎么办。

（以前用oracle的时候带不带“N”查询效率差别特别明显，今天用sql server测试并没有发现什么差别。还有我发现EF6会根据数据库中是nvarchar的时候才会生成带“N”的sql，oracle数据库没测试，有兴趣的同学可以测试下）

性能提升之AsNoTracking

我们看生成的sql

sql是生成的一模一样，但是执行时间却是4.8倍。原因仅仅只是第一条EF语句多加了一个AsNoTracking。

注意：

• AsNoTracking干什么的呢？无跟踪查询而已，也就是说查询出来的对象不能直接做修改。所以，我们在做数据集合查询显示，而又不需要对集合修改并更新到数据库的时候，一定不要忘记加上AsNoTracking。
• 如果查询过程做了select映射就不需要加AsNoTracking。如：db.Students.Where(t=>t.Name.Contains("张三")).select(t=>new (t.Name,t.Age)).ToList();

多字段组合排序（字符串）

要求：查询名字里面带有“张三”的学生，先按名字排序，再按年龄排序。

咦，不对啊。按名字排序被年龄排序覆盖了。我们应该用ThenBy来组合排序。

不错不错，正是我们想要的效果。如果你不想用ThenBy，且都是升序的话，我们也可以：

生成的sql是一样的。与OrderBy、ThenBy对应的降序有OrderByDescending、ThenByDescending。

看似好像很完美了。其实不然，我们大多数情况排序是动态的。比如，我们会更加前端页面不同的操作要求不同字段的不同排序。那我们后台应该怎么做呢？

当然，这样完成是没问题的，只要你愿意。可以这么多可能的判断有没有感觉非常SB？是的，我们当然有更好的解决方案。要是OrderBy可以直接传字符串？？？

解决方案：

1. guget下载System.Linq.Dynamic 
2. 导入System.Linq.Dynamic命名空间
3. 编写OrderBy的扩展方法

然后上面又长又臭的代码可以写成：

我们看下生成的sql：

和我们想要的效果完全符合，是不是感觉美美哒！！

lamdba条件组合

要求：根据不同情况查询，可能情况

1. 查询name=“张三” 的所有学生
2. 查询name=“张三” 或者 age=18的所有学生

实现代码：

是不是味到了同样的臭味。下面我们来灵活组装Lamdba条件。

解决方案：

（编辑：徐州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!