上述我們簡(jiǎn)單講解了幾個(gè)小問(wèn)題，這節(jié)我們?cè)賮?lái)看看如標(biāo)題EF Core中多次Include導(dǎo)致出現(xiàn)性能的問(wèn)題，廢話少說(shuō)，直接開(kāi)門(mén)見(jiàn)山。首先依然給出我們上一節(jié)的示例類：

接下來(lái)我們?cè)诳刂婆_(tái)進(jìn)行如下查詢：

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

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

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

接下來(lái)我們?cè)賮?lái)進(jìn)行如下查詢：

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

此時(shí)我們進(jìn)行如上查詢顯然不可取，因?yàn)橹苯泳偷綌?shù)據(jù)庫(kù)進(jìn)行SQL查詢了，我們需要返回IQueryable才行，同時(shí)根據(jù)主鍵查詢只能返回一條，所以我們改造成如下查詢：

因?yàn)榻酉聛?lái)還需要從上下文中加載導(dǎo)航屬性，所以這里我們需要去掉AsNoTracking，通過(guò)上下文加載指定實(shí)體導(dǎo)航屬性，我們可通過(guò)Load方法來(lái)加載，如下：

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

注意：上述博主采用的是穩(wěn)定版本3.0.1，其他版本未經(jīng)測(cè)試哦。其實(shí)對(duì)于查詢而言，還是建議采用Dapper或者走底層connection寫(xiě)原生SQL才是最佳，對(duì)于單表，用EF Core無(wú)可厚非，對(duì)于復(fù)雜查詢還是建議不要用EF Core，生成的SQL很不可控，為了圖方便，結(jié)果換來(lái)的將是CPU飆到飛起。好了，本節(jié)我們就到這里，感謝您的閱讀，我們下節(jié)見(jiàn)。

總結(jié)

以上是生活随笔為你收集整理的EntityFramework Core 3多次Include导致查询性能低之解决方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。