一、起因 

　　　上次做的是EF百萬(wàn)級(jí)數(shù)據(jù)的單表查詢，總結(jié)了一下，在200w以下的數(shù)據(jù)量的情況(Sql Server 2012)，EF是可以使用，但是由于查詢條件過(guò)于簡(jiǎn)單，且是單表查詢，EF只是負(fù)責(zé)生成Sql語(yǔ)句，對(duì)于一些簡(jiǎn)單的查詢，生成Sql語(yǔ)句的時(shí)間可以基本忽略，所以不僅沒(méi)有發(fā)揮出EF的優(yōu)勢(shì)，而且這樣的性能瓶頸基本可以說(shuō)是和數(shù)據(jù)庫(kù)完全有關(guān)的，這個(gè)鍋數(shù)據(jù)庫(kù)得背(數(shù)據(jù)庫(kù)：怪我了)。鑒于實(shí)際項(xiàng)目中多是多表的連接查詢，還有其他復(fù)雜的查詢，一向本著求真務(wù)實(shí)的思想的博主就趁此機(jī)會(huì)再次測(cè)試了一下EF的復(fù)雜的連接查詢什么的。說(shuō)實(shí)話，在測(cè)試之前我也不知道結(jié)果，只是為了自己以后用起來(lái)有個(gè)參考依據(jù)，也比總是聽(tīng)別人說(shuō)EF性能很差，嚇得都不敢用了要好。EF的性能到底有多差，或者說(shuō)可以勝任什么樣的場(chǎng)景，不吹不黑，我們就一起來(lái)看看，也好在以后的實(shí)際項(xiàng)目選型的時(shí)候參考一下。

二、關(guān)于很多ORM框架的對(duì)比測(cè)試

　　博主最近也看了不少關(guān)于ORM框架的測(cè)試，大多數(shù)都是增刪改幾千，幾萬(wàn)條的數(shù)據(jù)，這樣確實(shí)可以看出來(lái)性能的比較，但是實(shí)際項(xiàng)目中真的很少有這樣的情況，一次增刪改幾千幾萬(wàn)條數(shù)據(jù)的，我們做項(xiàng)目服務(wù)的都是用戶，按用戶的一次請(qǐng)求為一次數(shù)據(jù)庫(kù)上下文的操作，同一個(gè)上下文在這樣的一次請(qǐng)求中基本不可能同時(shí)提交這么多的數(shù)據(jù)操作，有人說(shuō)那要是成千上萬(wàn)的用戶同時(shí)呢，那就要考慮并發(fā)了，就不是本文所要討論的問(wèn)題了。所以這些測(cè)試能表明結(jié)果，但是不能表明實(shí)際問(wèn)題。另外在大多數(shù)對(duì)于EF的測(cè)試中，很多人忽略了EF對(duì)于實(shí)體的跟蹤，比如：

　　　　平面設(shè)計(jì)培訓(xùn),網(wǎng)頁(yè)設(shè)計(jì)培訓(xùn),美工培訓(xùn),游戲開(kāi)發(fā),動(dòng)畫培訓(xùn)

　　　　這些屬性雖然我不全知道是什么的東西，但是既然可以設(shè)置Enabled，就說(shuō)明是對(duì)性能有影響的，而且數(shù)據(jù)量越多，相信影響也越大，但其他多數(shù)ORM