十年河東，十年河西，莫欺少年窮。
EF就如同那個少年，ADO.NET則是一位壯年。畢竟ADO.NET出生在EF之前，而EF所走的路屬於應用ADO.NET。
也就是說：你所寫的LINQ查詢，最后還是要轉化為ADO.NET的SQL語句，轉化過程中無形降低了EF的執行效率。
但是，使用EF的一個好處就是系統便於維護，減少了系統開發時間，降低了生成成本。
OK，上述只是做個簡單的對比，那么在實際編碼過程中，我們應當怎樣提升EF的性能呢？
工欲善其事，必先利其器。
我們使用EF和在很大程度提高了開發速度，不過隨之帶來的是很多性能低下的寫法和生成不太高效的sql。
雖然我們可以使用SQL Server Profiler來監控執行的sql，不過個人覺得實屬麻煩，每次需要打開、過濾、清除、關閉。
在這里強烈推薦一個插件MiniProfiler。實時監控頁面請求對應執行的sql語句、執行時間。簡單、方便、針對性強。
如圖：
關於MiniProfiler的使用，大家可參考：MiniProfiler工具介紹(監控加載用時，EF生成的SQL語句)--EF，迷你監控器，哈哈哈
1、EF使用SqlQuery
上述已經說的很明白了，EF效率低於ADO.NET是因為LINQ-TO-SQL的過程消耗了時間。而使用SqlQuery則可以直接寫SQL語句。
當然，如果你想得到更快的執行速度，你也可以在數據庫上寫存儲過程PROC
關於SqlQuery的用法，在此不作解釋。
2、EF使用AsNoTracking()，無跟蹤查詢技術(查詢出來的數據不可以修改，如果你做了修改，你會發現修改並不成功)
2.1、測試修改：
var student = context.Student.AsNoTracking().Where(A => A.Id == 2).FirstOrDefault() ;
student.StuName = "毛毛";
context.SaveChanges();
上述代碼嘗試修改數據，程序運行完以后，我們會發現數據庫Id為2的學生的姓名並沒有修改，因此，采用無跟蹤查詢技術得到的數據是不可以進行修改的。
2.2、性能測試：
代碼測試如下：
View Code
性能對比如下：
注意：（因為我使用的是本地數據庫，所以效率差別不是很大，如果是遠程數據庫且數據量比較大，性能會提升很多，有測試證明：其性能可提升4~5倍）
- AsNoTracking干什么的呢？無跟蹤查詢而已，也就是說查詢出來的對象不能直接做修改。所以，我們在做數據集合查詢顯示，而又不需要對集合修改並更新到數據庫的時候，一定不要忘記加上AsNoTracking。
- 如果查詢過程做了select映射就不需要加AsNoTracking。如：db.Students.Where(t=>t.Name.Contains("張三")).select(t=>new (t.Name,t.Age)).ToList();
3、性能提升之AsNonUnicode
代碼測試如下：
public ActionResult Index()
{
var profiler = MiniProfiler.Current;
using (profiler.Step("查詢Student的數據"))
{
using (BingFaTestEntities context = new BingFaTestEntities())
{
var b = context.Student.Where(A => A.StuName=="趙剛").ToList();
}
}
using (profiler.Step("高性能查詢Student的數據"))
{
using (BingFaTestEntities context = new BingFaTestEntities())
{
var a = context.Student.AsNoTracking().Where(A => A.StuName == DbFunctions.AsNonUnicode("趙剛")).ToList();
}
}
return View();
}
性能對比如下：
從上圖可以看出，生成了兩條基本相同的SQL語句，唯獨不相同的地方是：不加AsNonUnicode SQL中會有 N，加了AsNonUnicode后，SQL中沒有N
使用 N 前綴（查詢過程中需要把數據庫默認格式轉化為Unicode 格式來查詢，因此：性能被拉低）
在服務器上執行的代碼中（例如在存儲過程和觸發器中）顯示的 Unicode 字符串常量必須以大寫字母 N 為前綴。即使所引用的列已定義為 Unicode 類型，也應如此。
不使用 N 前綴
如果不使用 N 前綴，字符串將轉換為數據庫的默認代碼格式。這可能導致不識別某些字符。
因此，關於 AsNonUnicode 的的使用，還要結合具體情況。
4、多字段組合排序（字符串）先按照學號排序，再按姓名排序(請將排序OrderBy放在構造LINQ的最后)
錯誤代碼如下：
using (profiler.Step("查詢Student的數據"))
{
using (BingFaTestEntities context = new BingFaTestEntities())
{
var b1 = context.Student.Where(A => A.StuName.StartsWith("王")).OrderBy(A => A.StuNum).OrderBy(A => A.StuName).ToList();
}
}
正確代碼如下：
using (profiler.Step("高性能查詢Student的數據"))
{
using (BingFaTestEntities context = new BingFaTestEntities())
{
var b2 = context.Student.Where(A => A.StuName.StartsWith("王")).OrderBy(A => A.StuNum).ThenBy(A => A.StuName).ToList();
}
}
由上圖得到的結果分析可知：錯誤代碼連續使用兩個OrderBy，導致后面的OrderBy覆蓋了前面的OrderBy，也就是說：錯誤代碼是按照姓名排列的。
因此，涉及連續排序時，要用ThenBy。
5、foreach循環的陷進
5.1、關於延遲加載
請看上圖紅框。為什么StudentId有值，而Studet為null？因為使用code first，需要設置導航屬性為virtual，才會加載延遲加載數據。
加了virtual后，我們就可以使用延遲加載了。但是，如果用上述的ForEach循環，會產生嚴重的性能問題。
如下：
我們通過 MiniProfiler工具 監控下生成的SQL語句，如下
生成了101條SQL語句，是不是很嚇人。
那我們應當怎么正確的使用懶加載呢？
解決方案：使用Include顯示連接查詢（注意:需要手動導入using System.Data.Entity 不然Include只能傳表名字符串）。
加上了Include后，懶加載就變成了顯示加載，也就是說帶有Virtual的懶加載字段信息會被一次加載出來，因此：使用 Include 后，只會生成一條SQL語句！
再看MiniProfiler的監控（瞬間101條sql變成了1條，這其中的性能可想而知。）
因此，性能會大大滴提升哦。
6、AutoMapper的使用
所謂AutoMapper即：自動映射，關於AutoMapper的使用，大家可參考我的博客：AutoMapper自動映射
下面結合數據庫來看如下示例：
數據表關系：
create table Dept
(
Id int identity(1,1) not null,
deptNum varchar(20) not null primary key,
deptName nvarchar(20) default('計算機科學與工程系'),
)
create table Student
(
Id int identity(1,1) not null,
StuNum varchar(20) primary key,
deptNum varchar(20) FOREIGN KEY (deptNum) REFERENCES Dept (deptNum),
StuName nvarchar(10),--
StuSex nvarchar(2) default('男'),
AddTime datetime default(getdate()),
)
很簡單。系表和學生表，有個外鍵deptNum，
EF中生成的DTO如下：
namespace BingFa.Entity
{
using System;
using System.Collections.Generic;
public partial class Student
{
public int Id { get; set; }
public string StuNum { get; set; }
public string deptNum { get; set; }
public string StuName { get; set; }
public string StuSex { get; set; }
public Nullable<System.DateTime> AddTime { get; set; }
public virtual Dept Dept { get; set; }
}
}
namespace BingFa.Entity
{
using System;
using System.Collections.Generic;
public partial class Dept
{
public Dept()
{
this.Student = new HashSet<Student>();
}
public int Id { get; set; }
public string deptNum { get; set; }
public string deptName { get; set; }
public virtual ICollection<Student> Student { get; set; }
}
}
Model層
public class StudentModel
{
public int Id { get; set; }
public string StuNum { get; set; }
public string deptNum { get; set; }
public string StuName { get; set; }
public string StuSex { get; set; }
public Nullable<System.DateTime> AddTime { get; set; }
public string deptName { get; set; }
}
測試代碼如下：
由上述代碼得知，我們需要根據導航屬性獲取系名。
同理，如果你有很多導航屬性，你亦可以多寫幾次 ForMember(......) ，但是這樣做會陷入延遲加載的陷阱。
針對上述的寫法，我們的監測如下：
可以看出竟然生成了兩條SQL語句，如果你用了N個導航屬性，那么就會生成N+1個SQL語句，這顯然是不能接受的，怎么辦呢？
同上述，ForEach的陷阱一樣，我們可以派上Include，如下：
加上了AsNoTracking無跟蹤查詢技術，這個是用來提升查詢性能。同時加上了Include，用於顯示加載，從而避免了懶加載生成SQL的問題。
監測如下：
由此可知，僅僅生成了一條SQL語句，SQL查詢性能也提升了很多，因此在使用AutoMapper時，切記別陷入這種陷阱。
其實，說白了，其實都是懶加載惹的禍，用不好的話，懶加載會讓你很累的哦。
7、count(*)被你用壞了嗎（Any的用法）
要求：查詢是否存在名字為“張三2”的學生。（你的代碼會怎樣寫呢？）
用第一種？第二種？第三種？呵呵，我以前就是使用的第一種，然后有人說“你count被你用壞了”，后來我想了想了怎么就被我用壞了呢？直到對比了這三個語句的性能后我知道了。
看到監控后，瞬間驚呆了，count(*)的性能竟然最低，Any的性能最高。性能之差竟有三百多倍，count確實被我用壞了。（我想，不止被我一個人用壞了吧。）
我們看到上面的Any干嘛的？官方解釋是：
我反復閱讀這個中文解釋，一直無法理解。甚至早有人也提出過同樣的疑問《實在看不懂MSDN關於 Any 的解釋》
所以我個人理解也是“確定集合中是否有元素滿足某一條件”。我們來看看any其他用法：
要求：查詢教過“張三”或“李四”的老師
實現代碼：
兩種方式，以前我會習慣寫第一種。當然我們看看生成過的sql和執行效率之后，看法改變了。
效率之差竟有近六倍。
我們再對比下count：
得出奇怪的結論：
- 在導航屬性里面使用count和使用any性能區別不大，反而FirstOrDefault() != null的方式性能最差。
- 在直接屬性判斷里面any和FirstOrDefault() != null性能區別不大，count性能要差的多。
- 所以，不管是直接屬性還是導航屬性我們都用any來判斷是否存在是最穩當的。
8、動態創建LINQ子查詢
查詢姓 張 李 王 的男人
LINQ 如下：
var Query = from P in persons1
where (P.Name.Contains("張") || P.Name.Contains("李") || P.Name.Contains("王"))&&P.Sex=="男"
select new PersonModel
{
Name = P.Name,
Sex = P.Sex,
Age = P.Age,
Money = P.Money
};
現在需求變更如下：查詢姓 張 李 王 的男人 並且 年齡要大於20歲
LINQ 變更如下：
var Query = from P in persons1
where (P.Name.Contains("張") || P.Name.Contains("李") || P.Name.Contains("王"))&&P.Sex=="男"&&P.Age>20
select new PersonModel
{
Name = P.Name,
Sex = P.Sex,
Age = P.Age,
Money = P.Money
};
好了，如果您認為上述構建WHERE子句的方式就是動態構建的話，那么本篇博客就沒有什么意義了！
那么什么樣的方式才是真正的動態構建呢？
OK，咱們進入正題：
在此我提出一個簡單需求如下：
我相信我的需求提出后，你用上述方式就寫不出來了，我的需求如下：
請根據數組中包含的姓氏進行查詢：
數組如下：
string[] xingList = new string[] { "趙", "錢", "孫", "李", "周", "吳", "鄭", "王", "馮", "陳" };
在這里，有人可能會立馬想到：分割數組，然后用十個 || 進行查詢就行了！
我要強調的是：如果數組是動態的呢？長度不定，包含的姓氏不確定呢？
呵呵，想必寫不出來了吧！
還好，LINQ也有自己的一套代碼可以實現（如果LINQ實現不了，那么早就沒人用LINQ了）：
由於代碼比較多，在此大家可參考：LINQ 如何動態創建 Where 子查詢
代碼如下：
View Code
需要指出的是：
Expression.Or(con, condition); 邏輯或運算
Expression.And(con, condition); 邏輯與運算
代碼分析：
生成的LINQ子查詢類似於：c=>c.Tags.Contains(s) || c=>c.Alias.Contains(Alias)....
9、真分頁與假分頁（了解 IQueryable，IEnumerable的區別）
大家都知道分頁是非常常用的功能，但是在使用EF寫分頁語句的時候，稍有不慎，真分頁便會成為假分頁：
上述兩個看似類似的LINQ語句，實際執行起來效率差了很多。其原因是ToList使用的位置，當你ToList()時，EF會將linq轉化為SQL，然后執行。
第一個LINQ我們可理解為：先把數據全部都查詢出來，然后分頁
第二個LINQ我們可理解為：只查詢分頁所需的N條數據。如果你有100萬條數據，第一種方法會全部查詢出來，第二種方法僅僅會查詢分頁所需的10條數據，其性能對比可想而知。
10、批量刪除和修改
不知道你是否研究過EF的插入刪除和修改操作，當你批量操作數據的時候，通過SQL Server Profiler可以明顯看到產生了大量的Insert，Update語句,效率非常低；因為他插入一條數據，會對應生成一條Insert語句，當你的list中有10萬條數據時，就會生成10萬條插入語句！不過還好咱們有對策：Entity Framework Extendeds ，EF擴展類完美解決批量操作問題：
要使用AddRange，一次性插入10萬條數據。
11、EF使用存儲過程
在此貼出我的存儲過程（我這個存儲過程也是處理並發的存儲過程），關於並發處理大家可參考：C# 數據庫並發的解決方案（通用版、EF版）
create proc LockProc --樂觀鎖控制並發
(
@ProductId int,
@IsSuccess bit=0 output
)
as
declare @count as int
declare @flag as TimeStamp
declare @rowcount As int
begin tran
select @count=ProductCount,@flag=VersionNum from Inventory where ProductId=@ProductId
update Inventory set ProductCount=@count-1 where VersionNum=@flag and ProductId=@ProductId
insert into InventoryLog values('插入一條數據，用於計算是否發生並發',GETDATE())
set @rowcount=@@ROWCOUNT
if @rowcount>0
set @IsSuccess=1
else
set @IsSuccess=0
commit tran
EF執行存儲過程的方法如下：
View Code
12、EF Contains、StartsWith、EndsWith
請看如下代碼：
View Code
生成了按照Unicode字符集進行的模糊查詢，生成的SQL帶N
如何優化呢？首先我們按照本篇博客第三條：3、性能提升之AsNonUnicode 我們按照數據庫默認編碼查詢來提升效率。
View Code
根據生成的SQL語句，可以看出查詢沒有帶N，執行時間為32.4秒，效率增加一倍。
除了上述優化之外，還要看公司項目的具體要求，如果要求進行雙向匹配，那么你只能老老實實的采用Contains，如果公司只要求單項匹配，你可以采用StartsWith、EndsWith
當然，要想模糊查詢相率高些，單項匹配當然最好，具體還要看項目需求哦
13、EF預熱
使用過EF的都知道針對所有表的第一次查詢都很慢，而同一個查詢查詢過一次后就會變得很快了。
假設場景：當我們的查詢編譯發布部署到服務器上時，第一個訪問網站的的人會感覺到頁面加載的十分緩慢，這就帶來了很不好的用戶體驗。
解決方案：在網站初始化時將數據表遍歷一遍
在Global文件的Application_Start方法中添加如下代碼（代碼如下（Entity Framework的版本至少是6.0才支持））：
using (var dbcontext = new BingFaTestEntities())
{
var objectContext = ((IObjectContextAdapter)dbcontext).ObjectContext;
var mappingCollection = (StorageMappingItemCollection)objectContext.MetadataWorkspace.GetItemCollection(DataSpace.CSSpace);
mappingCollection.GenerateViews(new List<EdmSchemaError>());
}
我們做個測試：
12.1、第一次運行程序，不進行EF預熱的：
12.2、同樣重新運行程序，進行EF預熱的：
執行速度：
由上圖可以，在進行了EF預熱后，加載時間為856.9毫秒，而不進行EF預熱加載用時1511.5毫秒，由此可知，加上預熱代碼后，第一次加載速度幾乎快了一倍。