快捷導(dǎo)航

MongoDB排序時(shí)內(nèi)存大小限制與創(chuàng)建索引的注意事項(xiàng)詳解

更新時(shí)間：2022年05月06日 15:59:59 作者：小白碼上飛

在數(shù)據(jù)量超大的情形下,任何數(shù)據(jù)庫系統(tǒng)在創(chuàng)建索引時(shí)都是一個(gè)耗時(shí)的大工程,下面這篇文章主要給大家介紹了關(guān)于MongoDB排序時(shí)內(nèi)存大小限制與創(chuàng)建索引的注意事項(xiàng)的相關(guān)資料,需要的朋友可以參考下

參數(shù)internalQueryExecMaxBlockingSortBytes

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

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

返回如下結(jié)果：

// 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")
}
}
}

所以解決排序時(shí)內(nèi)存使用超過32MB的問題，有兩個(gè)方法：

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

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

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

MongoDB 4.3的internalQueryMaxBlockingSortMemoryUsageBytes

我準(zhǔn)備在本地的MongoDB上復(fù)現(xiàn)這個(gè)問題，于是把這個(gè)表直接導(dǎo)入到本地MongoDB中。結(jié)果發(fā)現(xiàn)排序時(shí)并沒有報(bào)錯(cuò)。使用上面的命令查看internalQueryExecMaxBlockingSortBytes參數(shù)的值時(shí)，返回如下結(jié)果：

[17][ProtocolError] no option found to get

Google了一下，發(fā)現(xiàn)了MongoDB的官方網(wǎng)站上的兩個(gè)相關(guān)JIRA。

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

第二個(gè)JIRA [SERVER-50767] internalQueryExecMaxBlockingSortBytes causing config exception on mongod load - Mongo中，Comments里提到了，新的internalQueryMaxBlockingSortMemoryUsageBytes參數(shù)，默認(rèn)值從32MB改成了100MB。也許我的這個(gè)表使用100MB內(nèi)存進(jìn)行排序就夠用了，所以沒有報(bào)錯(cuò)。

所以在4.3以上的版本（本機(jī)是5.0.4），執(zhí)行以下命令：

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

可以看到查詢結(jié)果：

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

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

排序字段如何加索引？

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

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

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

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

那么熟悉的報(bào)錯(cuò)就又回來了。

是的！機(jī)智的MongoDB并不會(huì)像我們想的那樣，先用上A的索引，從而省點(diǎn)力氣。他依舊會(huì)把全部的數(shù)據(jù)丟到內(nèi)存里排序……

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

哦，不行喲，還是那個(gè)報(bào)錯(cuò)。

所以，當(dāng)多字段排序時(shí)，你必須要建一個(gè)包含了這些字段的復(fù)合索引，且要注意以下幾點(diǎn)：

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

總結(jié)

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

到此這篇關(guān)于MongoDB排序時(shí)內(nèi)存大小限制與創(chuàng)建索引注意事項(xiàng)的文章就介紹到這了,更多相關(guān)MongoDB排序內(nèi)存限制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: