一次關於mongodb性能踩坑的總結

發現性能問題

上一次導入數據後，發現系統十分的卡頓，可是才僅僅1000多條數據而已，怎麼會讓系統變得如何的卡頓呢?因而我開始走在排查系統卡頓的緣由的道路上。

首先，先定位問題是出如今前端上仍是後端上。打開瀏覽器，輸入localhost:7000, 而後F12打開netword。啓動後端項目，查看log。切換回瀏覽器，右鍵刷新。結果發現好多些問題:

1. 請求發送的個數比較多。
2. 後端每一個接口的響應時間都比較長，都超過了1s，這明顯有問題。
3. 前端不少請求從: 發送請求到頁面渲染成功所須要的時間大於了10S(發送請求時間+後端接口響應時間+下載資源時間，即回傳數據時間+頁面渲染時間)。

從上面這幾個現象能夠看出:

1. 後端有明顯的問題。
2. 前端暫時沒有什麼問題。

好好分析一下，爲何後端每一個接口的響應時間都會超過1s，mongodb是出了名的速度快，通常查詢數據就幾十ms，普通查詢也不會超過300ms。可是看到的接口響應時間倒是超過了1s，有的仍是明顯3，4s。

苦苦冥想，細細推測，思來想去，都不知道是怎麼回事，最後只有採用刪代碼的方式來定位問題了。

當刪除相似於下面的代碼的時候

Schema.virtual('affixes', {
    ref: 'Affix',
    localField: '_id',
    foreignField: 'businessId',
});

這個時候，發現後端接口的響應時間正常了，能夠判斷，這段代碼起到了必定的做用，可是這只是簡單的連表查詢而已。爲何就致使接口響應時間多那麼多呢？

我繼續分析，進入到controller.js裏面，將與表關聯查詢的代碼找出來，終於，我快要發現元兇了，刪除這幾行代碼，ok，一樣，響應時間正常了。

仔細分析這幾行代碼，發現了一個很重要的事情: 竟然是全表查詢！！並且是3張表關聯的全表查詢！！因此...查詢的數據差很少就是這個量: 2000 * 2000 * 2000, 也怪不得爲何響應時間會超出1s了。

第一個元兇已經被抓住了。可是我還並不知道爲何前端從請求到渲染成功的時間怎麼會超過10s，這簡直不能忍。

清空network，而後刷新，從新發送請求，能夠看見發送了5個左右的請求，而查看後端的log發現其中3個請求都是在作表關聯的全表查詢，而且reply的時候仍是將全部的數據都返回到前端裏去了。

ok，如今我大概已經知道爲何會有超過10s的響應時間了，下載的數據量也比較大，因此響應時間 = 發送請求時間 + 後端處理時間 + 下載資源時間 + 渲染時間, 因爲數據量比較大，因此致使最後的兩個時間也不小。

如今大概已經都找出了爲何頁面會卡頓而且遲緩。緣由就是沒有作後端分頁，系統裏用的是前端分頁。

性能優化總結

1. 查詢數據避免多張表關聯全表查詢。
2. 先過濾再關聯查詢，而不是先查詢再關聯表。
3. react裏多個列表，必定要設置key。
4. 分頁必定不要前端作，由於數據量大了確定要崩掉的。