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控制。
- 正常的解決方式是新增索引，但是索引要包括全部參與排序的欄位，且要遵循字首匹配策略。