EntityFramework Core 3多次Include導(dǎo)致查詢性能低的解決方案是什么

這篇文章將為大家詳細(xì)講解有關(guān)EntityFramework Core 3多次Include導(dǎo)致查詢性能低的解決方案是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

這節(jié)我們再來看看如標(biāo)題EF Core中多次Include導(dǎo)致出現(xiàn)性能的問題，廢話少說，直接開門見山。首先依然給出我們上一節(jié)的示例類：

接下來我們在控制臺進(jìn)行如下查詢：

如上圖所示，生成的SQL語句一點毛病都么有，對吧，接下來我們來查詢導(dǎo)航屬性Posts，如下：

咦，不應(yīng)該是INNER JOIN嗎，但最終生成的SQL語句我們可以看到居然是LEFT JOIN，關(guān)鍵是我們對Post類中的BlogId并未設(shè)置為可空，對吧，是不是很有意思。同時通過ORDER BY對兩個表的主鍵都進(jìn)行了排序。這就是問題的引發(fā)點，接下來我們再引入兩個類：

上述我們聲明了分類和標(biāo)簽，我們知道博客有分類和標(biāo)簽，所以博客類中有對分類和標(biāo)簽的導(dǎo)航屬性（這里我們先不關(guān)心關(guān)系到底是一對一還是一對多等關(guān)系），然后修改博客類，如下：

接下來我們再來進(jìn)行如下查詢：

此時和變更追蹤沒有半毛錢關(guān)系，我們看看最終生成的SQL語句，是不是很驚訝，假設(shè)單個類中對應(yīng)多個導(dǎo)航屬性，最終生成的SQL語句就是繼續(xù)LEFT JOIN和ORDER BY，可想其性能將是多么的低下。那么我們應(yīng)該如何解決這樣的問題呢？既然是和Include有關(guān)系，每增加一個導(dǎo)航屬性即增加一個Include將會增加一個LEFT JOIN和ORDER BY，那么我們何不分開單獨查詢呢，說完就開干。

此時我們進(jìn)行如上查詢顯然不可取，因為直接就到數(shù)據(jù)庫進(jìn)行SQL查詢了，我們需要返回IQueryable才行，同時根據(jù)主鍵查詢只能返回一條，所以我們改造成如下查詢：

因為接下來還需要從上下文中加載導(dǎo)航屬性，所以這里我們需要去掉AsNoTracking，通過上下文加載指定實體導(dǎo)航屬性，我們可通過Load方法來加載，如下：

通過上述生成的SQL語句，我們知道這才是我們想要的結(jié)果，上述代碼看起來有點不是那么好看，似乎沒有更加優(yōu)美的寫法了，當(dāng)然這里我只是在控制臺中進(jìn)行演示，為了吞吐，將上述修改為異步查詢則是最佳可行方式。比生成一大堆LEFT JOIN和ORDER BY性能好太多太多。

注意：上述博主采用的是穩(wěn)定版本3.0.1，其他版本未經(jīng)測試哦。其實對于查詢而言，還是建議采用Dapper或者走底層connection寫原生SQL才是最佳，對于單表，用EF Core無可厚非，對于復(fù)雜查詢還是建議不要用EF Core，生成的SQL很不可控，為了圖方便，結(jié)果換來的將是CPU飆到飛起。

關(guān)于EntityFramework Core 3多次Include導(dǎo)致查詢性能低的解決方案是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。