1. 索引不是银弹先搞清楚MongoDB在什么场景下会“慢”很多人第一次接触MongoDB索引是因为某条查询突然变慢了。翻日志、看监控发现一个原本几十毫秒的查询涨到了几秒第一反应就是“加个索引吧”。这个直觉不算错但如果连慢在哪、为什么慢都没搞清楚就动手加索引大概率会陷入“加了索引还是慢”或者“索引越加越多、写入越来越慢”的泥潭。MongoDB的查询慢通常逃不出三种情况。第一种是集合扫描也就是没有可用的索引MongoDB只能把整个集合的文档从头到尾读一遍。数据量小的时候感觉不出来一旦文档数上了几十万扫描的代价就非常明显。第二种是索引选择不当明明有索引但查询优化器选了一个区分度很差的索引导致扫描了大量索引条目后才命中目标文档。第三种是索引本身没问题但查询写法让索引失效比如对索引字段做了函数运算、用了不支持的运算符或者排序方向与索引方向不匹配。理解这三种情况是后面所有索引操作的前提。因为索引的本质是用额外的存储空间和写入开销换取查询时的定位效率。它就像一本书的目录有了目录你不需要翻遍整本书找某一章但每往书里加一页内容你都得顺手更新目录书越厚、目录越多更新目录的成本就越高。MongoDB的索引也是这个道理每个索引都意味着每次插入、更新、删除文档时都要同步维护这个索引结构。所以我在实际项目里判断“要不要加索引”时会先问自己三个问题这个查询的频率高不高返回的结果集占集合的比例大不大这个字段的区分度高不高如果查询频率低、结果集又大、字段区分度还差那加索引的收益可能还不如优化查询本身。索引操作的核心不是“会建索引”而是“知道什么时候该建、建什么样的、什么时候该删”。2. 单字段索引的创建与验证从一次真实的慢查询说起2.1 用explain看清查询的真实执行路径假设有一个存储订单的集合文档结构大概长这样{ _id: ObjectId(...), orderNo: ORD20240101001, userId: U10086, status: paid, amount: 299.00, createdAt: ISODate(2024-01-01T10:00:00Z) }某天运营反馈按订单号查订单特别慢。我先不急着加索引而是用explain看一下执行计划db.orders.find({ orderNo: ORD20240101001 }).explain(executionStats)返回结果里重点看几个字段。winningPlan.stage如果是COLLSCAN说明走的是集合扫描如果是IXSCAN说明走了索引。executionStats.totalDocsExamined表示扫描了多少文档executionStats.nReturned表示返回了多少文档。如果totalDocsExamined远大于nReturned比如扫描了十万条只返回一条那就是典型的“扫描效率低”。那次的结果是COLLSCANtotalDocsExamined是十二万多nReturned是1。问题很明确没有索引全表扫描。这时候加索引就是对的。2.2 创建单字段索引并对比前后差异创建索引的命令很直接db.orders.createIndex({ orderNo: 1 })这里的1表示升序-1表示降序。对于单字段索引来说升序和降序在查询时都能用因为MongoDB可以反向扫描索引。但如果是复合索引方向就有讲究了后面会细说。创建完再跑一次同样的explainwinningPlan.stage变成了IXSCANtotalDocsExamined降到了1nReturned也是1。查询耗时从原来的几百毫秒降到了个位数毫秒。这就是索引最直观的价值。不过这里有个细节值得注意createIndex是异步的在数据量很大的集合上创建索引会消耗较多资源。生产环境里我一般会加两个参数db.orders.createIndex( { orderNo: 1 }, { background: true, name: idx_orderNo } )background: true让索引在后台构建不阻塞其他读写操作。虽然从4.2版本开始MongoDB的索引构建机制已经优化前台后台的差异没那么大了但显式写上background仍然是一个好习惯尤其是在老版本或者混合版本的环境里。name参数给索引起一个有意义的名字方便后续管理和排查。默认名字是orderNo_1这种字段多了以后根本分不清哪个是哪个。2.3 索引命中的边界条件加完索引不代表万事大吉。我见过不少人加完索引发现查询还是慢原因往往出在查询写法上。比如下面这几种情况索引就命中不了对索引字段做了类型转换db.orders.find({ orderNo: 12345 })而orderNo存的是字符串MongoDB不会自动把数字转成字符串去匹配索引。用了不支持的运算符比如$where、$regex非前缀匹配这类索引基本帮不上忙。查询条件里字段顺序和复合索引不匹配这个在复合索引部分展开。所以每次加完索引我都会用explain再验证一遍确认IXSCAN真的生效了而不是想当然地认为“加了索引就一定走索引”。3. 复合索引的字段顺序一个被低估的决策点3.1 最左前缀原则不是背出来的是推出来的复合索引是MongoDB索引里最容易踩坑的地方。假设我们经常按userId和status两个字段联合查询创建了这样一个索引db.orders.createIndex({ userId: 1, status: 1 })这个索引能支持的查询模式遵循所谓的“最左前缀原则”。简单说索引先按userId排序userId相同的再按status排序。所以下面这些查询能用上索引db.orders.find({ userId: U10086 }) db.orders.find({ userId: U10086, status: paid }) db.orders.find({ status: paid, userId: U10086 }) // 查询优化器会自动调整顺序但下面这个查询用不上db.orders.find({ status: paid })因为索引的第一层排序是userId跳过userId直接查status就像跳过目录的第一级直接找第二级索引结构帮不上忙。这个原则很多人背得滚瓜烂熟但真正做设计时还是会搞错顺序。我的经验是把区分度最高的字段放在最左边。区分度高意味着这个字段的值重复少能快速缩小扫描范围。比如userId可能有几千个不同值而status只有“待支付、已支付、已发货、已完成”四五种那userId放前面就比status放前面效率高得多。3.2 排序方向对复合索引的影响复合索引的另一个坑是排序方向。假设有查询需要按userId升序、createdAt降序排列db.orders.find({ userId: U10086 }).sort({ createdAt: -1 })如果索引是{ userId: 1, createdAt: 1 }这个排序就用不上索引因为索引里createdAt是升序排列的而查询要降序。这时候需要建一个方向匹配的索引db.orders.createIndex({ userId: 1, createdAt: -1 })或者反过来{ userId: -1, createdAt: 1 }也行因为MongoDB可以反向扫描整个索引。但{ userId: 1, createdAt: 1 }和{ userId: -1, createdAt: -1 }是等价的而{ userId: 1, createdAt: -1 }和{ userId: -1, createdAt: 1 }是等价的。这个规律记不住也没关系用explain看winningPlan里有没有SORT阶段就行如果有SORT说明排序没走索引需要调整。3.3 复合索引与覆盖查询覆盖查询是复合索引的一个高级用法。如果一个查询需要的所有字段都在索引里MongoDB就可以直接从索引返回结果不需要回表读文档。比如db.orders.createIndex({ userId: 1, status: 1, amount: 1 }) db.orders.find( { userId: U10086, status: paid }, { userId: 1, status: 1, amount: 1, _id: 0 } )这个查询只返回索引里包含的字段并且显式排除了_id就能触发覆盖查询。explain里会看到totalDocsExamined为0因为压根没读文档。覆盖查询对性能提升非常明显尤其是在高并发场景下能大幅减少磁盘I/O。但覆盖查询有个容易忽略的点_id字段默认会返回除非显式排除。很多人写了投影但忘了排除_id结果覆盖查询没生效还纳闷为什么totalDocsExamined不是0。4. 索引的日常维护查看、删除与重建4.1 查看现有索引避免重复建设随着业务迭代集合上的索引会越来越多。我接手过一个项目某个集合上有十几个索引其中好几个是功能重复的。比如已经有了{ userId: 1, status: 1 }又建了一个{ userId: 1 }后者完全是前者的前缀属于冗余索引。查看索引的命令db.orders.getIndexes()返回结果里会列出所有索引的名称、键和选项。我一般会定期跑一遍这个命令对照慢查询日志看看哪些索引从来没被用过。MongoDB提供了$indexStats聚合阶段来统计索引使用情况db.orders.aggregate([{ $indexStats: {} }])返回结果里的accesses.ops表示这个索引被使用的次数。如果某个索引的ops长期为0那它大概率是冗余的可以考虑删除。但要注意$indexStats统计的是自上次MongoDB进程启动以来的数据重启后会重置所以最好观察一段时间的累计值再下结论。4.2 删除索引的正确姿势删除索引用dropIndexdb.orders.dropIndex(idx_orderNo)或者按键删除db.orders.dropIndex({ orderNo: 1 })删除索引本身很快但有个前提不能删除_id索引也不能删除正在被唯一性约束依赖的索引。如果某个索引是唯一索引删除前要确认没有业务逻辑依赖它的唯一性保证否则可能出现重复数据。我踩过一次坑删了一个看似没用的索引结果那个索引是某个唯一约束的一部分删完之后业务侧出现了重复插入。所以删除前一定要用getIndexes()看清楚索引的unique选项并且和业务方确认没有依赖。4.3 索引重建的时机与方式索引用久了可能会出现碎片尤其是频繁增删改的集合。碎片会导致索引扫描效率下降。判断是否需要重建可以看db.collection.stats()里的indexSizes和实际数据量的比例如果索引大小远超预期可能存在碎片。重建索引有两种方式。一种是删除后重建db.orders.dropIndex(idx_orderNo) db.orders.createIndex({ orderNo: 1 }, { name: idx_orderNo })另一种是用reIndex命令db.orders.reIndex()reIndex会重建集合上的所有索引在数据量大时非常耗时而且会阻塞其他操作。生产环境我更倾向于逐个删除重建配合background: true把影响降到最低。重建最好安排在业务低峰期并且提前在从节点上验证一遍确认没问题再操作主节点。5. 那些让索引失效的写法几个真实案例5.1 正则表达式的前缀陷阱正则查询在MongoDB里很常见但并不是所有正则都能用索引。只有前缀匹配的正则才能利用索引比如db.orders.find({ orderNo: /^ORD2024/ })这个查询可以用上orderNo的索引因为它是从字符串开头匹配的。但如果是db.orders.find({ orderNo: /2024/ })这种包含匹配就用不上索引只能全表扫描。如果业务确实需要模糊匹配可以考虑用全文索引或者把关键字拆出来单独存字段。5.2 类型不一致导致的索引失效MongoDB是弱类型的同一个字段在不同文档里可能是不同的BSON类型。比如userId有的存字符串U10086有的存数字10086。这种情况下即使建了索引查询时如果类型不匹配索引也可能失效。我遇到过一个案例某次数据迁移时部分文档的userId被写成了数字类型导致按字符串查询时这些文档查不到而且查询计划变成了集合扫描。排查了很久才发现是类型问题。后来统一了写入规范并且在应用层做了类型校验才彻底解决。5.3 数组字段索引的注意事项对数组字段建索引时MongoDB会为数组里的每个元素都建一条索引条目这叫多键索引。多键索引能加速数组元素的查询但有几个限制不能用于覆盖查询不能对数组字段做排序优化。而且如果数组很大索引体积会膨胀得很快。比如给tags数组字段建索引db.articles.createIndex({ tags: 1 })查询db.articles.find({ tags: mongodb })能用上索引。但如果查询是db.articles.find({ tags: { $all: [mongodb, index] } })索引的效率就会打折扣因为需要合并多个索引扫描结果。6. 索引与写入性能的平衡一个绕不开的取舍6.1 每个索引都有写入成本前面一直在讲索引对查询的好处但索引不是免费的。每次插入文档MongoDB都要为每个索引插入一条索引条目每次更新文档如果更新涉及索引字段就要更新对应的索引条目每次删除文档也要删除索引条目。假设一个集合有10个索引那么一次插入操作实际上要写11次1次文档10次索引。写入放大非常明显。在高写入场景下索引过多会直接拖垮写入吞吐量。我做过一个压测同一个集合3个索引和8个索引对比写入QPS差了将近一倍。所以索引数量要克制够用就行不要“以防万一”地加一堆。6.2 如何判断索引是否值得保留判断一个索引是否值得保留我一般看三个指标使用频率、对查询性能的提升幅度、对写入性能的影响。如果某个索引使用频率很低但占用空间大、维护成本高那就果断删掉。具体操作上可以结合$indexStats和慢查询日志。先找出所有慢查询看它们分别用了哪些索引再对照$indexStats看哪些索引从来没被慢查询用到。两边一交叉冗余索引就浮出水面了。另外对于低频但偶发的复杂查询可以考虑用部分索引来降低维护成本。部分索引只对满足条件的文档建索引比如只对status: paid的订单建索引db.orders.createIndex( { createdAt: 1 }, { partialFilterExpression: { status: paid } } )这样索引体积更小写入成本更低但只对特定查询有效。用之前要确认查询条件能匹配partialFilterExpression否则索引不会被使用。6.3 TTL索引一种特殊的写入优化TTL索引是MongoDB里比较特殊的一类索引它可以让文档在指定时间后自动过期删除。比如日志集合只保留最近7天的数据db.logs.createIndex( { createdAt: 1 }, { expireAfterSeconds: 604800 } )604800是7天的秒数。MongoDB会有一个后台线程定期扫描TTL索引删除过期文档。这个删除操作也是要维护索引的但相比手动清理TTL索引把清理逻辑交给了数据库应用层不用再写定时任务。不过TTL索引有个限制它只能基于日期类型字段而且删除不是精确到秒的后台线程每60秒跑一次所以实际删除时间可能有延迟。对时效性要求极高的场景不能完全依赖TTL。7. 索引监控与调优把explain用透7.1 explain的三种模式explain支持三种模式queryPlanner、executionStats和allPlansExecution。默认是queryPlanner只返回查询优化器选择的计划不实际执行。executionStats会实际执行查询并返回统计信息是我最常用的模式。allPlansExecution会返回所有候选计划的执行情况适合分析为什么优化器选了某个计划而不是另一个。db.orders.find({ userId: U10086 }).explain(executionStats)看executionStats时重点对比totalDocsExamined和nReturned。理想情况下totalDocsExamined应该接近nReturned。如果前者远大于后者说明索引效率不高可能需要调整索引或查询。7.2 用hint强制指定索引有时候查询优化器会选错索引尤其是当集合上有多个相似索引时。这时候可以用hint强制指定db.orders.find({ userId: U10086, status: paid }) .hint({ userId: 1, status: 1 })hint在调试阶段很有用可以验证某个索引是否真的比优化器选的索引更好。但生产环境要慎用因为一旦索引被删除或改名hint会导致查询报错。我一般只在排查问题时临时用确认问题后要么调整索引设计要么优化查询写法而不是长期依赖hint。7.3 慢查询日志的配置与解读MongoDB的慢查询日志通过profiling功能开启。可以设置一个阈值比如超过100毫秒的查询记录到system.profile集合db.setProfilingLevel(1, { slowms: 100 })1表示只记录慢查询2表示记录所有操作。生产环境一般用1避免日志量过大。查看慢查询db.system.profile.find().sort({ ts: -1 }).limit(10)返回结果里会包含查询语句、执行时间、扫描文档数等信息。我习惯定期导出慢查询日志按查询模式归类找出最耗时的几类查询然后针对性地优化索引。8. 几个容易忽略的索引细节8.1 索引的排序规则与大小写MongoDB支持为索引指定排序规则比如大小写不敏感db.users.createIndex( { username: 1 }, { collation: { locale: en, strength: 2 } } )strength: 2表示忽略大小写。这样查询username: Alice和username: alice都能命中同一条索引。但要注意查询时也必须指定相同的collation否则索引不会被使用db.users.find({ username: Alice }) .collation({ locale: en, strength: 2 })这个细节很容易漏漏了就会发现索引明明建了却用不上。8.2 稀疏索引与存在性查询稀疏索引只对包含索引字段的文档建索引。如果集合里很多文档没有某个字段用稀疏索引可以减小索引体积db.users.createIndex({ email: 1 }, { sparse: true })但稀疏索引有个坑它不能用于$exists: false的查询因为不包含该字段的文档压根不在索引里。而且从MongoDB 4.2开始稀疏索引和部分索引的功能有重叠部分索引更灵活所以我更倾向于用部分索引替代稀疏索引。8.3 唯一索引与重复键处理唯一索引能保证字段值的唯一性但创建时如果集合里已经有重复值创建会失败。这时候需要先清理重复数据或者用dropDups选项老版本支持新版本已移除。新版本的做法是先找出重复值手动处理后再建唯一索引。db.users.createIndex({ email: 1 }, { unique: true })如果插入重复值MongoDB会抛出E11000错误。应用层要捕获这个错误并做相应处理而不是让异常直接冒泡。9. 从索引设计反推数据模型索引设计不只是查询优化的问题它还会反过来影响数据模型。比如如果发现某个查询总是需要跨集合关联那可能说明数据模型需要调整把关联字段内嵌到文档里用内嵌文档的索引来加速查询。我经历过一个项目最初把用户信息和订单分开存查询时要先查用户再查订单两次查询。后来把常用的用户信息冗余到订单文档里并在冗余字段上建索引一次查询就能搞定。虽然增加了数据冗余和维护成本但查询性能提升了一个数量级。另一个经验是索引字段尽量选那些写入后不怎么变的字段。如果某个字段频繁更新而它上面又有索引那每次更新都要维护索引写入成本很高。这种情况下可以考虑把频繁更新的字段和稳定字段分开存或者用其他方式规避。索引操作看起来是MongoDB里比较基础的内容但真正用好并不容易。我的体会是不要为了加索引而加索引每次加索引之前先用explain确认问题加完之后再用explain验证效果定期用$indexStats清理冗余索引。把这几个动作变成习惯索引就不会成为负担而是真正能提升性能的工具。
1. 索引不是银弹先搞清楚MongoDB在什么场景下会“慢”很多人第一次接触MongoDB索引是因为某条查询突然变慢了。翻日志、看监控发现一个原本几十毫秒的查询涨到了几秒第一反应就是“加个索引吧”。这个直觉不算错但如果连慢在哪、为什么慢都没搞清楚就动手加索引大概率会陷入“加了索引还是慢”或者“索引越加越多、写入越来越慢”的泥潭。MongoDB的查询慢通常逃不出三种情况。第一种是集合扫描也就是没有可用的索引MongoDB只能把整个集合的文档从头到尾读一遍。数据量小的时候感觉不出来一旦文档数上了几十万扫描的代价就非常明显。第二种是索引选择不当明明有索引但查询优化器选了一个区分度很差的索引导致扫描了大量索引条目后才命中目标文档。第三种是索引本身没问题但查询写法让索引失效比如对索引字段做了函数运算、用了不支持的运算符或者排序方向与索引方向不匹配。理解这三种情况是后面所有索引操作的前提。因为索引的本质是用额外的存储空间和写入开销换取查询时的定位效率。它就像一本书的目录有了目录你不需要翻遍整本书找某一章但每往书里加一页内容你都得顺手更新目录书越厚、目录越多更新目录的成本就越高。MongoDB的索引也是这个道理每个索引都意味着每次插入、更新、删除文档时都要同步维护这个索引结构。所以我在实际项目里判断“要不要加索引”时会先问自己三个问题这个查询的频率高不高返回的结果集占集合的比例大不大这个字段的区分度高不高如果查询频率低、结果集又大、字段区分度还差那加索引的收益可能还不如优化查询本身。索引操作的核心不是“会建索引”而是“知道什么时候该建、建什么样的、什么时候该删”。2. 单字段索引的创建与验证从一次真实的慢查询说起2.1 用explain看清查询的真实执行路径假设有一个存储订单的集合文档结构大概长这样{ _id: ObjectId(...), orderNo: ORD20240101001, userId: U10086, status: paid, amount: 299.00, createdAt: ISODate(2024-01-01T10:00:00Z) }某天运营反馈按订单号查订单特别慢。我先不急着加索引而是用explain看一下执行计划db.orders.find({ orderNo: ORD20240101001 }).explain(executionStats)返回结果里重点看几个字段。winningPlan.stage如果是COLLSCAN说明走的是集合扫描如果是IXSCAN说明走了索引。executionStats.totalDocsExamined表示扫描了多少文档executionStats.nReturned表示返回了多少文档。如果totalDocsExamined远大于nReturned比如扫描了十万条只返回一条那就是典型的“扫描效率低”。那次的结果是COLLSCANtotalDocsExamined是十二万多nReturned是1。问题很明确没有索引全表扫描。这时候加索引就是对的。2.2 创建单字段索引并对比前后差异创建索引的命令很直接db.orders.createIndex({ orderNo: 1 })这里的1表示升序-1表示降序。对于单字段索引来说升序和降序在查询时都能用因为MongoDB可以反向扫描索引。但如果是复合索引方向就有讲究了后面会细说。创建完再跑一次同样的explainwinningPlan.stage变成了IXSCANtotalDocsExamined降到了1nReturned也是1。查询耗时从原来的几百毫秒降到了个位数毫秒。这就是索引最直观的价值。不过这里有个细节值得注意createIndex是异步的在数据量很大的集合上创建索引会消耗较多资源。生产环境里我一般会加两个参数db.orders.createIndex( { orderNo: 1 }, { background: true, name: idx_orderNo } )background: true让索引在后台构建不阻塞其他读写操作。虽然从4.2版本开始MongoDB的索引构建机制已经优化前台后台的差异没那么大了但显式写上background仍然是一个好习惯尤其是在老版本或者混合版本的环境里。name参数给索引起一个有意义的名字方便后续管理和排查。默认名字是orderNo_1这种字段多了以后根本分不清哪个是哪个。2.3 索引命中的边界条件加完索引不代表万事大吉。我见过不少人加完索引发现查询还是慢原因往往出在查询写法上。比如下面这几种情况索引就命中不了对索引字段做了类型转换db.orders.find({ orderNo: 12345 })而orderNo存的是字符串MongoDB不会自动把数字转成字符串去匹配索引。用了不支持的运算符比如$where、$regex非前缀匹配这类索引基本帮不上忙。查询条件里字段顺序和复合索引不匹配这个在复合索引部分展开。所以每次加完索引我都会用explain再验证一遍确认IXSCAN真的生效了而不是想当然地认为“加了索引就一定走索引”。3. 复合索引的字段顺序一个被低估的决策点3.1 最左前缀原则不是背出来的是推出来的复合索引是MongoDB索引里最容易踩坑的地方。假设我们经常按userId和status两个字段联合查询创建了这样一个索引db.orders.createIndex({ userId: 1, status: 1 })这个索引能支持的查询模式遵循所谓的“最左前缀原则”。简单说索引先按userId排序userId相同的再按status排序。所以下面这些查询能用上索引db.orders.find({ userId: U10086 }) db.orders.find({ userId: U10086, status: paid }) db.orders.find({ status: paid, userId: U10086 }) // 查询优化器会自动调整顺序但下面这个查询用不上db.orders.find({ status: paid })因为索引的第一层排序是userId跳过userId直接查status就像跳过目录的第一级直接找第二级索引结构帮不上忙。这个原则很多人背得滚瓜烂熟但真正做设计时还是会搞错顺序。我的经验是把区分度最高的字段放在最左边。区分度高意味着这个字段的值重复少能快速缩小扫描范围。比如userId可能有几千个不同值而status只有“待支付、已支付、已发货、已完成”四五种那userId放前面就比status放前面效率高得多。3.2 排序方向对复合索引的影响复合索引的另一个坑是排序方向。假设有查询需要按userId升序、createdAt降序排列db.orders.find({ userId: U10086 }).sort({ createdAt: -1 })如果索引是{ userId: 1, createdAt: 1 }这个排序就用不上索引因为索引里createdAt是升序排列的而查询要降序。这时候需要建一个方向匹配的索引db.orders.createIndex({ userId: 1, createdAt: -1 })或者反过来{ userId: -1, createdAt: 1 }也行因为MongoDB可以反向扫描整个索引。但{ userId: 1, createdAt: 1 }和{ userId: -1, createdAt: -1 }是等价的而{ userId: 1, createdAt: -1 }和{ userId: -1, createdAt: 1 }是等价的。这个规律记不住也没关系用explain看winningPlan里有没有SORT阶段就行如果有SORT说明排序没走索引需要调整。3.3 复合索引与覆盖查询覆盖查询是复合索引的一个高级用法。如果一个查询需要的所有字段都在索引里MongoDB就可以直接从索引返回结果不需要回表读文档。比如db.orders.createIndex({ userId: 1, status: 1, amount: 1 }) db.orders.find( { userId: U10086, status: paid }, { userId: 1, status: 1, amount: 1, _id: 0 } )这个查询只返回索引里包含的字段并且显式排除了_id就能触发覆盖查询。explain里会看到totalDocsExamined为0因为压根没读文档。覆盖查询对性能提升非常明显尤其是在高并发场景下能大幅减少磁盘I/O。但覆盖查询有个容易忽略的点_id字段默认会返回除非显式排除。很多人写了投影但忘了排除_id结果覆盖查询没生效还纳闷为什么totalDocsExamined不是0。4. 索引的日常维护查看、删除与重建4.1 查看现有索引避免重复建设随着业务迭代集合上的索引会越来越多。我接手过一个项目某个集合上有十几个索引其中好几个是功能重复的。比如已经有了{ userId: 1, status: 1 }又建了一个{ userId: 1 }后者完全是前者的前缀属于冗余索引。查看索引的命令db.orders.getIndexes()返回结果里会列出所有索引的名称、键和选项。我一般会定期跑一遍这个命令对照慢查询日志看看哪些索引从来没被用过。MongoDB提供了$indexStats聚合阶段来统计索引使用情况db.orders.aggregate([{ $indexStats: {} }])返回结果里的accesses.ops表示这个索引被使用的次数。如果某个索引的ops长期为0那它大概率是冗余的可以考虑删除。但要注意$indexStats统计的是自上次MongoDB进程启动以来的数据重启后会重置所以最好观察一段时间的累计值再下结论。4.2 删除索引的正确姿势删除索引用dropIndexdb.orders.dropIndex(idx_orderNo)或者按键删除db.orders.dropIndex({ orderNo: 1 })删除索引本身很快但有个前提不能删除_id索引也不能删除正在被唯一性约束依赖的索引。如果某个索引是唯一索引删除前要确认没有业务逻辑依赖它的唯一性保证否则可能出现重复数据。我踩过一次坑删了一个看似没用的索引结果那个索引是某个唯一约束的一部分删完之后业务侧出现了重复插入。所以删除前一定要用getIndexes()看清楚索引的unique选项并且和业务方确认没有依赖。4.3 索引重建的时机与方式索引用久了可能会出现碎片尤其是频繁增删改的集合。碎片会导致索引扫描效率下降。判断是否需要重建可以看db.collection.stats()里的indexSizes和实际数据量的比例如果索引大小远超预期可能存在碎片。重建索引有两种方式。一种是删除后重建db.orders.dropIndex(idx_orderNo) db.orders.createIndex({ orderNo: 1 }, { name: idx_orderNo })另一种是用reIndex命令db.orders.reIndex()reIndex会重建集合上的所有索引在数据量大时非常耗时而且会阻塞其他操作。生产环境我更倾向于逐个删除重建配合background: true把影响降到最低。重建最好安排在业务低峰期并且提前在从节点上验证一遍确认没问题再操作主节点。5. 那些让索引失效的写法几个真实案例5.1 正则表达式的前缀陷阱正则查询在MongoDB里很常见但并不是所有正则都能用索引。只有前缀匹配的正则才能利用索引比如db.orders.find({ orderNo: /^ORD2024/ })这个查询可以用上orderNo的索引因为它是从字符串开头匹配的。但如果是db.orders.find({ orderNo: /2024/ })这种包含匹配就用不上索引只能全表扫描。如果业务确实需要模糊匹配可以考虑用全文索引或者把关键字拆出来单独存字段。5.2 类型不一致导致的索引失效MongoDB是弱类型的同一个字段在不同文档里可能是不同的BSON类型。比如userId有的存字符串U10086有的存数字10086。这种情况下即使建了索引查询时如果类型不匹配索引也可能失效。我遇到过一个案例某次数据迁移时部分文档的userId被写成了数字类型导致按字符串查询时这些文档查不到而且查询计划变成了集合扫描。排查了很久才发现是类型问题。后来统一了写入规范并且在应用层做了类型校验才彻底解决。5.3 数组字段索引的注意事项对数组字段建索引时MongoDB会为数组里的每个元素都建一条索引条目这叫多键索引。多键索引能加速数组元素的查询但有几个限制不能用于覆盖查询不能对数组字段做排序优化。而且如果数组很大索引体积会膨胀得很快。比如给tags数组字段建索引db.articles.createIndex({ tags: 1 })查询db.articles.find({ tags: mongodb })能用上索引。但如果查询是db.articles.find({ tags: { $all: [mongodb, index] } })索引的效率就会打折扣因为需要合并多个索引扫描结果。6. 索引与写入性能的平衡一个绕不开的取舍6.1 每个索引都有写入成本前面一直在讲索引对查询的好处但索引不是免费的。每次插入文档MongoDB都要为每个索引插入一条索引条目每次更新文档如果更新涉及索引字段就要更新对应的索引条目每次删除文档也要删除索引条目。假设一个集合有10个索引那么一次插入操作实际上要写11次1次文档10次索引。写入放大非常明显。在高写入场景下索引过多会直接拖垮写入吞吐量。我做过一个压测同一个集合3个索引和8个索引对比写入QPS差了将近一倍。所以索引数量要克制够用就行不要“以防万一”地加一堆。6.2 如何判断索引是否值得保留判断一个索引是否值得保留我一般看三个指标使用频率、对查询性能的提升幅度、对写入性能的影响。如果某个索引使用频率很低但占用空间大、维护成本高那就果断删掉。具体操作上可以结合$indexStats和慢查询日志。先找出所有慢查询看它们分别用了哪些索引再对照$indexStats看哪些索引从来没被慢查询用到。两边一交叉冗余索引就浮出水面了。另外对于低频但偶发的复杂查询可以考虑用部分索引来降低维护成本。部分索引只对满足条件的文档建索引比如只对status: paid的订单建索引db.orders.createIndex( { createdAt: 1 }, { partialFilterExpression: { status: paid } } )这样索引体积更小写入成本更低但只对特定查询有效。用之前要确认查询条件能匹配partialFilterExpression否则索引不会被使用。6.3 TTL索引一种特殊的写入优化TTL索引是MongoDB里比较特殊的一类索引它可以让文档在指定时间后自动过期删除。比如日志集合只保留最近7天的数据db.logs.createIndex( { createdAt: 1 }, { expireAfterSeconds: 604800 } )604800是7天的秒数。MongoDB会有一个后台线程定期扫描TTL索引删除过期文档。这个删除操作也是要维护索引的但相比手动清理TTL索引把清理逻辑交给了数据库应用层不用再写定时任务。不过TTL索引有个限制它只能基于日期类型字段而且删除不是精确到秒的后台线程每60秒跑一次所以实际删除时间可能有延迟。对时效性要求极高的场景不能完全依赖TTL。7. 索引监控与调优把explain用透7.1 explain的三种模式explain支持三种模式queryPlanner、executionStats和allPlansExecution。默认是queryPlanner只返回查询优化器选择的计划不实际执行。executionStats会实际执行查询并返回统计信息是我最常用的模式。allPlansExecution会返回所有候选计划的执行情况适合分析为什么优化器选了某个计划而不是另一个。db.orders.find({ userId: U10086 }).explain(executionStats)看executionStats时重点对比totalDocsExamined和nReturned。理想情况下totalDocsExamined应该接近nReturned。如果前者远大于后者说明索引效率不高可能需要调整索引或查询。7.2 用hint强制指定索引有时候查询优化器会选错索引尤其是当集合上有多个相似索引时。这时候可以用hint强制指定db.orders.find({ userId: U10086, status: paid }) .hint({ userId: 1, status: 1 })hint在调试阶段很有用可以验证某个索引是否真的比优化器选的索引更好。但生产环境要慎用因为一旦索引被删除或改名hint会导致查询报错。我一般只在排查问题时临时用确认问题后要么调整索引设计要么优化查询写法而不是长期依赖hint。7.3 慢查询日志的配置与解读MongoDB的慢查询日志通过profiling功能开启。可以设置一个阈值比如超过100毫秒的查询记录到system.profile集合db.setProfilingLevel(1, { slowms: 100 })1表示只记录慢查询2表示记录所有操作。生产环境一般用1避免日志量过大。查看慢查询db.system.profile.find().sort({ ts: -1 }).limit(10)返回结果里会包含查询语句、执行时间、扫描文档数等信息。我习惯定期导出慢查询日志按查询模式归类找出最耗时的几类查询然后针对性地优化索引。8. 几个容易忽略的索引细节8.1 索引的排序规则与大小写MongoDB支持为索引指定排序规则比如大小写不敏感db.users.createIndex( { username: 1 }, { collation: { locale: en, strength: 2 } } )strength: 2表示忽略大小写。这样查询username: Alice和username: alice都能命中同一条索引。但要注意查询时也必须指定相同的collation否则索引不会被使用db.users.find({ username: Alice }) .collation({ locale: en, strength: 2 })这个细节很容易漏漏了就会发现索引明明建了却用不上。8.2 稀疏索引与存在性查询稀疏索引只对包含索引字段的文档建索引。如果集合里很多文档没有某个字段用稀疏索引可以减小索引体积db.users.createIndex({ email: 1 }, { sparse: true })但稀疏索引有个坑它不能用于$exists: false的查询因为不包含该字段的文档压根不在索引里。而且从MongoDB 4.2开始稀疏索引和部分索引的功能有重叠部分索引更灵活所以我更倾向于用部分索引替代稀疏索引。8.3 唯一索引与重复键处理唯一索引能保证字段值的唯一性但创建时如果集合里已经有重复值创建会失败。这时候需要先清理重复数据或者用dropDups选项老版本支持新版本已移除。新版本的做法是先找出重复值手动处理后再建唯一索引。db.users.createIndex({ email: 1 }, { unique: true })如果插入重复值MongoDB会抛出E11000错误。应用层要捕获这个错误并做相应处理而不是让异常直接冒泡。9. 从索引设计反推数据模型索引设计不只是查询优化的问题它还会反过来影响数据模型。比如如果发现某个查询总是需要跨集合关联那可能说明数据模型需要调整把关联字段内嵌到文档里用内嵌文档的索引来加速查询。我经历过一个项目最初把用户信息和订单分开存查询时要先查用户再查订单两次查询。后来把常用的用户信息冗余到订单文档里并在冗余字段上建索引一次查询就能搞定。虽然增加了数据冗余和维护成本但查询性能提升了一个数量级。另一个经验是索引字段尽量选那些写入后不怎么变的字段。如果某个字段频繁更新而它上面又有索引那每次更新都要维护索引写入成本很高。这种情况下可以考虑把频繁更新的字段和稳定字段分开存或者用其他方式规避。索引操作看起来是MongoDB里比较基础的内容但真正用好并不容易。我的体会是不要为了加索引而加索引每次加索引之前先用explain确认问题加完之后再用explain验证效果定期用$indexStats清理冗余索引。把这几个动作变成习惯索引就不会成为负担而是真正能提升性能的工具。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
