實體框架效能真的那麼差

問自己問題並回答自己很有趣！

這玩意兒很可怕，因為它變幻莫測，需要額外的精力去關注操作的細節，優化效能直接優化SQL查詢不直觀嗎？

EF是大而完整的，但是我發現EF沒用，EF效能現在提公升了很多，但是這裡就是說執行SQL的效能在預熱之後，小專案**有額外的資源給你幾十秒的預熱時間，基本都是冷啟動; 大型專案對效能的要求特別高，對於大型專案，EF真的不想移動資料庫，萬一需求發生變化，可以換人。

實體框架是執行緒安全的。

提高實體框架效能的注意事項如下：

分頁時，請嘗試在資料庫中分頁。

盡可能禁用延遲載入，並盡可能使用預載入和顯式載入的查詢。

如果啟用了延遲載入，這將導致多個往返資料庫查詢。 這將不可避免地導致效能不佳。

注意交易的簡潔性。

使用事務時，盡量將查詢語句或其他要在事務外執行的語句移到事務外消聲。 否則，如果乙個事務耗時過長，很容易造成資源死鎖的問題。

如果您不考慮刪除和修改出現的實體，請使用 notracking

批量刪除修改，不要先查詢實體，再逐個刪除修改。 這樣會產生大量的句子和句子，效率肯定會很低。

使用查詢的已編譯查詢，將自動快取 LINQ 查詢。 但是，使用已編譯的查詢比自動快取更有效。

對於複雜的查詢，請隨時監控生成的查詢語句。

畢竟，EF 生成的語句往往比生成的語句更複雜，因此有必要考慮是否以其他方式提高效能。

您好：EF可以支援多個資料庫，如SQL Server、MySQL、Oracle，它可以做資料庫的遷移，幾乎可以不變**，但是EDMX實際上是乙個配置檔案，也包含了目標資料庫的資訊。

如果要通過更改配置來切換資料庫，需要執行以下幾項操作：

1：3 應仔細閱讀資料庫的提供程式，以確認哪些功能不受支援，採用支援的最小函式集，將它們寫入開發規範，並指定不允許寫入哪些 LINQ 語句。

2：為3種資料庫準備3套EDMX，比較簡單，也可以在DLL之外生成SSLD之類的，然後動態修改，但容易出錯，麻煩大做。 無論是 dbfirset 還是 codefirst，都可以根據目標資料庫型別輕鬆重新生成 edmx。

3：更改連線字串，在EF的連線字串中，需要指定傳統連線字串EF的提供者對應的EDMX配置（SSLD、CSDL、MSL），並按照1和2配置這3個元素作為目標資料庫的對應配置，理論上，你的**可以直接執行。