Sparse Indexes vs unique index
wxh:PRIMARY> db.coll.ensureIndex({id2:1} ,{unique:true})
{
"err" : "E11000 duplicate key error index: test.coll.$id2_1 dup key: { : null }",
"code" : 11000,
"n" : 0,
"lastOp" : Timestamp(1390372177, 1),
"connectionId" : 1818,
"ok" : 1
}
發現在id2上建立唯一索引建不上去,原來mongodb會把null值作為一個“真”值處理,那麼就不允許一個欄位上有超過2個null值存在。
這種情況下,可以透過Sparse Indexes解決這個問題
wxh:PRIMARY> db.coll.ensureIndex({id2:1} ,{unique:true ,"sparse":true})
wxh:PRIMARY> db.coll.stats()
{
"ns" : "test.coll",
"count" : 3,
"size" : 112,
"avgObjSize" : 37.333333333333336,
"storageSize" : 4096,
"numExtents" : 1,
"nindexes" : 2,
"lastExtentSize" : 4096,
"paddingFactor" : 1,
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : 16352,
"indexSizes" : {
"_id_" : 8176,
"id2_1" : 8176
},
"ok" : 1
}
Sparse Indexes可能導致的問題:
> db.foo.find({"x" : {"$ne" : 2}})
{ "_id" : 0 }
{ "_id" : 1, "x" : 1 }
{ "_id" : 3, "x" : 3 }
如果你在x上建立了Sparse Indexes索引,那麼查詢的結果就會返回:
> db.foo.find({"x" : {"$ne" : 2}})
{ "_id" : 1, "x" : 1 }
{ "_id" : 3, "x" : 3 }
這是由於{ "_id" : 0 }並不包含在Sparse Indexes索引裡,而查詢的計劃卻走了索引掃描
{
"err" : "E11000 duplicate key error index: test.coll.$id2_1 dup key: { : null }",
"code" : 11000,
"n" : 0,
"lastOp" : Timestamp(1390372177, 1),
"connectionId" : 1818,
"ok" : 1
}
發現在id2上建立唯一索引建不上去,原來mongodb會把null值作為一個“真”值處理,那麼就不允許一個欄位上有超過2個null值存在。
這種情況下,可以透過Sparse Indexes解決這個問題
wxh:PRIMARY> db.coll.ensureIndex({id2:1} ,{unique:true ,"sparse":true})
wxh:PRIMARY> db.coll.stats()
{
"ns" : "test.coll",
"count" : 3,
"size" : 112,
"avgObjSize" : 37.333333333333336,
"storageSize" : 4096,
"numExtents" : 1,
"nindexes" : 2,
"lastExtentSize" : 4096,
"paddingFactor" : 1,
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : 16352,
"indexSizes" : {
"_id_" : 8176,
"id2_1" : 8176
},
"ok" : 1
}
Sparse Indexes可能導致的問題:
> db.foo.find({"x" : {"$ne" : 2}})
{ "_id" : 0 }
{ "_id" : 1, "x" : 1 }
{ "_id" : 3, "x" : 3 }
如果你在x上建立了Sparse Indexes索引,那麼查詢的結果就會返回:
> db.foo.find({"x" : {"$ne" : 2}})
{ "_id" : 1, "x" : 1 }
{ "_id" : 3, "x" : 3 }
這是由於{ "_id" : 0 }並不包含在Sparse Indexes索引裡,而查詢的計劃卻走了索引掃描
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22034023/viewspace-1074062/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle 19c Concepts(03):Indexes and Index-Organized TablesOracleIndexZed
- mysql中key 、primary key 、unique key 與index區別MySqlIndex
- PostgreSQL DBA(119) - pgAdmin(LIMIT:Index Scan vs Bitmap Index Scan)SQLMITIndex
- Bitmap Indexing in DBMS Bitmap Index vs. B-tree Index low cardinalityIndex
- PostgreSQL DBA(177) - Serializability Isolation(Index vs NonIndex)SQLIndex
- Oracle vs PostgreSQL Develop(31) - Index Only ScanOracleSQLdevIndex
- Oracle vs PostgreSQL Develop(30) - Index&Case whenOracleSQLdevIndex
- Sparse Table
- 翻譯(九)——Clustered Indexes: Stairway to SQL Server Indexes Level 3IndexAISQLServer
- Range Sparse Net
- unique 用法
- Unique Array
- sparse_cross_attentionROS
- [20180510]20 Indexes.txtIndex
- PostgreSQL DBA(45) - Hypothetical Indexes in PostgreSQLSQLIndex
- PTA甲級——Be Unique
- SQL Server Unique ConstratintsSQLServer
- MySQL 8 新特性之Invisible IndexesMySqlIndex
- RMQ_第一彈_Sparse TableMQ
- [20202117]Function based indexes and cursor sharing.txtFunctionIndex
- scipy.sparse的一些整理
- UVA 11572 Unique snowflakes (滑窗)
- LeetCode之Unique Email Addresses(Kotlin)LeetCodeAIKotlin
- PostgreSQL DBA(194) - Unique&NULLSQLNull
- [20220414]Function based indexes and cursor sharing2.txtFunctionIndex
- 「Neural Factorization Machines for Sparse Predictive Analytics」- 論文摘要Mac
- [20201104]關於稀疏檔案(sparse files).txt
- PostgreSQL DBA(159) - pgAdmin(Allow vacuum command to process indexes in paralleSQLIndex
- 深入 C++ 的 unique_ptrC++
- LeetCode Unique Paths(062)解法總結LeetCode
- LeetCode之Unique Morse Code Words(Kotlin)LeetCodeKotlin
- Index of /virtualboxIndex
- PostgreSQL:INDEXSQLIndex
- Oracle 19C 無法啟用Auto Indexes特性OracleIndex
- cmu15545筆記-索引併發控制(Concurrent Indexes)筆記索引Index
- oracle invisible index與unusable index的區別OracleIndex
- 慎用PHP的unset、array_unique方法PHP
- mysql索引型別:FULLTEXT、NORMAL、SPATIAL、UNIQUEMySql索引型別ORM
- [LeetCode] 2841. Maximum Sum of Almost Unique SubarrayLeetCode