MongoDB排序時內存大小限制與創建索引的注意事項詳解

線上服務的MongoDB中有一個很大的表，我查詢時使用了sort()根據某個字段進行排序，結果報了下面這個錯誤：

[Error] Executor error during find command :: caused by :: Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.
at line 0, column 0

這是個非常常見的MongoDB報錯了。因為MongoDB處理排序時，如果排序的字段沒有建立索引，會把全表都丟到內存中處理。

If MongoDB cannot use an index or indexes to obtain the sort order, MongoDB must perform a blocking sort operation on the data. A blocking sort indicates that MongoDB must consume and process all input documents to the sort before returning results.

而內存的大小并不是無限使用的，MongoDB的默認設置是32MB。一旦數據量超過32MB，則會報錯。

參數internalQueryExecMaxBlockingSortBytes

32MB這個限制是在參數internalQueryExecMaxBlockingSortBytes中控制。你可以在MongoDB的客戶端上直接查看這個參數的值，執行以下語句：

db.runCommand({
    getParameter: 1,
    "internalQueryExecMaxBlockingSortBytes": 1
})

返回如下結果：

// 1
{
"internalQueryExecMaxBlockingSortBytes": NumberInt("33554432"),
"ok": 1,
"operationTime": Timestamp(1651142670, 1),
"$clusterTime": {
"clusterTime": Timestamp(1651142670, 1),
"signature": {
"hash": BinData(0, "X09M2FBji5f+FOwaK/nLTv4+Ybs="),
"keyId": NumberLong("7080087363631710209")
}
}
}

所以解決排序時內存使用超過32MB的問題，有兩個方法：

給排序的字段加索引。具體怎么加索引，會在后面細講。

修改internalQueryExecMaxBlockingSortBytes參數的大小，使用命令如下：

db.adminCommand({
    setParameter: 1,
    internalQueryExecMaxBlockingSortBytes: 104857600
}) 

MongoDB 4.3的internalQueryMaxBlockingSortMemoryUsageBytes

我準備在本地的MongoDB上復現這個問題，于是把這個表直接導入到本地MongoDB中。結果發現排序時并沒有報錯。使用上面的命令查看internalQueryExecMaxBlockingSortBytes參數的值時，返回如下結果：

[17][ProtocolError] no option found to get

Google了一下，發現了MongoDB的官方網站上的兩個相關JIRA。

第一個JIRA [SERVER-44053] Rename setParameter for maximum memory usage of blocking sort - MongoDB Jira里表示，在4.3.1版本時，因為參數命名描述不清楚，所以將參數internalQueryExecMaxBlockingSortBytes改為了internalQueryMaxBlockingSortMemoryUsageBytes。這解釋了為什么我執行查詢參數的語句時，沒有返回結果。

第二個JIRA [SERVER-50767] internalQueryExecMaxBlockingSortBytes causing config exception on mongod load - Mongo中，Comments里提到了，新的internalQueryMaxBlockingSortMemoryUsageBytes參數，默認值從32MB改成了100MB。也許我的這個表使用100MB內存進行排序就夠用了，所以沒有報錯。

所以在4.3以上的版本（本機是5.0.4），執行以下命令：

db.runCommand({
    getParameter: 1,
    "internalQueryMaxBlockingSortMemoryUsageBytes": 1
})

可以看到查詢結果：

{
    "internalQueryMaxBlockingSortMemoryUsageBytes": NumberInt("104857600"),
    "ok": 1
}

而服務器上的MongoDB版本為4.0.3，因此是爆出來最上面的問題。

排序字段如何加索引？

這是個很簡單的問題，你用哪個字段排序，就對哪個字段加索引就好了。比如我要根據A字段進行排序，則增加A字段的索引。

-- 加索引
db.bigMongoTable.createIndex({
    "A": 1
});
-- 查詢
db.bigMongoTable.find({}).sort({
    "A": 1
});

但是如果我改主意了，我要根據A、B兩個字段做排序：

db.bigMongoTable.find({}).sort({
    "A": 1,
    "B": 1
});

那么熟悉的報錯就又回來了。

是的！機智的MongoDB并不會像我們想的那樣，先用上A的索引，從而省點力氣。他依舊會把全部的數據丟到內存里排序……

那我再加個B字段的索引吧，畢竟在MongoDB查詢的時候，對兩個字段分別建單鍵索引，靈活性比直接建一個復合索引要好一些，而且MongoDB的索引交集也可以讓這兩個單鍵索引實現和復合索引一樣的效果。

哦，不行喲，還是那個報錯。

所以，當多字段排序時，你必須要建一個包含了這些字段的復合索引，且要注意以下幾點：

• 查詢時參與排序的多個字段的順序，要和創建的索引每個字段的順序保持一致。比如你創建的索引是：db.bigMongoTable.createIndex({"A":1,"B":1,"C":1});那么你的排序語句也要按照順序如下：sort({"A":1,"B":1,"C":1})。如果你調換A和B的順序，如下：sort({"B":1,"A":1,"C":1})，則索引不會生效。
• 參與查詢的字段少于索引的字段，則要保證符合前綴匹配。還是第一點里的索引，如果排序語句是這樣：sort({"A":1,"B":1})，則索引繼續生效。如果是這樣：sort({"A":1,"C":1})，則無法生效。這個你可以理解成和MySQL類似，索引都是按照最左匹配規則去觸發的，一條索引的中間部分跳過了就無效了。
• 參與sort的字段的排序方式，要和創建索引時的排序方式保持完全一致，或者完全相反。對于第一點里的索引，如果查詢sort({"A":-1,"B":1})或者sort({"A":1,"B":-1})，索引則不會生效。只有在查詢sort({"A":1,"B":1})或者sort({"A":-1,"B":-1})時，索引才會生效。

總結

• MongoDB的查詢結果在進行排序時，如果排序字段沒有添加索引，會將數據全部放到內存中計算。如果數據量過大，超過配置的內存大小，則會報錯。
• 4.3版本之前，使用內存的最大值通過參數internalQueryExecMaxBlockingSortBytes控制，默認為32MB。4.3版本之后，通過參數internalQueryMaxBlockingSortMemoryUsageBytes控制。
• 正常的解決方式是添加索引，但是索引要包括全部參與排序的字段，且要遵循前綴匹配策略。

到此這篇關于MongoDB排序時內存大小限制與創建索引注意事項的文章就介紹到這了,更多相關MongoDB排序內存限制內容請搜索本站以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持本站！

香港服務器租用

版權聲明：本站文章來源標注為YINGSOO的內容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網站，禁止在非www.333abb.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內容來源于網友推薦、互聯網收集整理而來，僅供學習參考，不代表本站立場，如有內容涉嫌侵權，請聯系alex-e#qq.com處理。