一、起因
上次做的是EF百萬級數(shù)據(jù)的單表查詢，總結(jié)了一下，在200w以下的數(shù)據(jù)量的情況(Sql Server 2012)，EF是可以使用，但是由于查詢條件過于簡單，且是單表查詢，EF只是負(fù)責(zé)生成Sql語句，對于一些簡單的查詢，生成Sql語句的時間可以基本忽略，所以不僅沒有發(fā)揮出EF的優(yōu)勢，而且這樣的性能瓶頸基本可以說是和數(shù)據(jù)庫完全有關(guān)的，這個鍋數(shù)據(jù)庫得背(數(shù)據(jù)庫：怪我了)。鑒于實際項目中多是多表的連接查詢，還有其他復(fù)雜的查詢，一向本著求真務(wù)實的思想的博主就趁此機(jī)會再次測試了一下EF的復(fù)雜的連接查詢什么的。說實話，在測試之前我也不知道結(jié)果，只是為了自己以后用起來有個參考依據(jù)，也比總是聽別人說EF性能很差，嚇得都不敢用了要好。EF的性能到底有多差，或者說可以勝任什么樣的場景，不吹不黑，我們就一起來看看，也好在以后的實際項目選型的時候參考一下。
二、關(guān)于很多ORM框架的對比測試
博主最近也看了不少關(guān)于ORM框架的測試，大多數(shù)都是增刪改幾千，幾萬條的數(shù)據(jù)，這樣確實可以看出來性能的比較，但是實際項目中真的很少有這樣的情況，一次增刪改幾千幾萬條數(shù)據(jù)的，我們做項目服務(wù)的都是用戶，按用戶的一次請求為一次數(shù)據(jù)庫上下文的操作，同一個上下文在這樣的一次請求中基本不可能同時提交這么多的數(shù)據(jù)操作，有人說那要是成千上萬的用戶同時呢，那就要考慮并發(fā)了，就不是本文所要討論的問題了。所以這些測試能表明結(jié)果，但是不能表明實際問題。另外在大多數(shù)對于EF的測試中，很多人忽略了EF對于實體的跟蹤，比如：
這些屬性雖然我不全知道是什么的東西，但是既然可以設(shè)置Enabled，就說明是對性能有影響的，而且數(shù)據(jù)量越多，相信影響也越大，但其他多數(shù)ORM
