說到 ef，估計又有很多人來噴它了，說它效率低等等，但是從辯證的角度去考慮，ef這款orm框架的優點在中小型專案中，發揮的極其出色
暫且說說個人的體會吧，如若錯誤，還望廣大群友指正：
1、**簡潔，易於維護，lambda表示式的應用使**更加易讀。ps: 比如 where、orderby 等。
2、開發效率高。是想一下，就僅僅寫乙個兩個表關聯查詢，ef一行**搞定，原生sql 還得寫個 left join 啥的。你懂得！
但是：（劃重點來了，本人在實際專案中使用ef將近一年，其中也遇到各種各樣的坑，現在集中總結一下，順帶給新學習的小朋友填坑，）ps:老司機就繞道吧，容易打臉。。。
1、多用select ，比如乙個訂單表裡面有三十個字段，你也許只需要裡面其中的五六個字段，一下子全查出來是不是太浪費系統效能了呢。
2、不要在迴圈中查詢資料庫，這樣是非常不明智的。驗證影響系統的效能。可以將需要迴圈的資料先從資料庫中查詢出來，然後在記憶體中迴圈遍歷。這樣效率是最高的。
4、ef的懶載入。估計使用過ef的小夥伴 都踩過懶載入的坑，ef經常報 上下文物件已釋放的問題，哈哈，所以對於懶載入還是要慎用的。本人給的參考就是，盡量使用渴望載入。畢竟你取的資料都是你所需要的啊。嘿嘿。。。不過我遇到有乙個場景還是使用懶載入比較好。eg:當兩個表是一對多的關係時，且多的一方，資料較多，如果使用include()將多的一方資料全部渴望載入出來，這無疑對記憶體是乙個挑戰（不在乎記憶體的就自行跳過本段），比較好的實現方式就是，先將主表資訊查詢出來進行進行遍歷，如果找到業務需要的資料後，則 在通過懶載入 將其關聯資料載入出來，但這樣會產生兩次資料庫連線。有利有弊。
5、了解 iqueryable 和 ienumable 的實質區別，兩者是不一樣的，前者是返回生成的sql,後者是到資料庫執行後返回的結果
查詢效能優化
查詢效能優化 查詢的生命週期 客戶端 伺服器 查詢快取 命令解析 預處理 優化器優化 查詢執行引擎 查詢生命週期每一子任務響應時間都可能慢，但核心是執行任務。分析步驟 確認是否在檢索大量超過需要的資料。訪問了太多行或列 確認伺服器是否在分析大量超過需要的資料行。2.1 衡量查詢開銷三大指標 2.掃瞄...
查詢效能優化
查詢的最基本的原因是 訪問的資料太多。可以通過減少訪問的資料兩進行優化 具體步驟如下 確認應用程式是否檢索大量超過需要是資料 訪問行列太多 返回三個表的全部資料列 select from sakila.actor inner join sakila.film actor using actor id...
查詢效能優化
查詢後面加limit 只查詢需要的列 如果查詢相同的資料，可以用快取儲存起來 mysql最簡單衡量查詢開銷的三個指標 響應時間，掃瞄行數，返回行數 響應時間包括服務時間和排隊時間，服務時間就是資料庫處理這個查詢所花的時間，排隊時間一般常見的是i o和鎖等待所花大的事件 理想的情況下,掃瞄行數等於返回...