一、索引失效的典型场景
在日常使用MongoDB时，经常会遇到查询突然变慢的情况。这时候多半是索引出了问题。就像汽车突然油耗飙升，我们需要检查是不是发动机出了问题。以下是几个最常见的索引失效场景：
- 查询条件不匹配索引顺序
// 假设我们有个复合索引 {name:1, age:1}
// 错误查询：条件顺序与索引不一致
db.users.find({age: 25, name: "张三"})
// 这个查询无法有效使用索引，因为条件顺序与索引定义相反
// 正确做法：保持条件顺序与索引一致
db.users.find({name: "张三", age: 25})
- 使用了范围查询后的等值查询
// 复合索引 {status:1, createTime:1}
// 错误查询：范围查询在前
db.orders.find({createTime: {$gt: ISODate("2023-01-01")}, status: "completed"})
// 这样会导致索引部分失效
// 正确做法：等值查询在前
db.orders.find({status: "completed", createTime: {$gt: ISODate("2023-01-01")}})
- 使用了$or操作符
// 索引 {name:1} 和 {age:1}
// 低效查询：
db.users.find({$or: [{name: "张三"}, {age: 25}]})
// $or会导致每个条件单独使用索引，然后合并结果，效率较低
// 优化方案：考虑使用$in或重构查询
db.users.find({name: {$in: ["张三", "李四"]}})
二、索引优化的实用策略
知道了问题所在，接下来我们看看如何优化。就像医生开药方，需要对症下药。
- 使用索引覆盖查询
// 索引 {name:1, age:1}
// 普通查询：需要回表
db.users.find({name: "张三"}, {age:1, _id:0})
// 虽然用了索引，但还是要读取文档
// 优化为覆盖查询：
db.users.find({name: "张三"}, {name:1, age:1, _id:0})
// 这样查询可以完全通过索引完成，无需读取文档
- 合理使用复合索引
// 设计复合索引时考虑ESR原则：
// E(Equality)等值查询字段
// S(Sort)排序字段
// R(Range)范围查询字段
// 例如有个查询：
db.orders.find({
status: "completed", // 等值
createTime: {$gt: someDate}, // 范围
amount: {$lt: 1000} // 范围
}).sort({priority: -1}) // 排序
// 最佳索引设计：
db.orders.createIndex({
status: 1, // 等值字段在前
priority: -1, // 排序字段
createTime: 1, // 范围字段
amount: 1 // 范围字段
})
- 使用索引提示
// 当查询优化器选择了不理想的索引时
db.users.find({name: "张三", age: 25}).hint({name:1, age:1})
// 强制使用指定索引
// 查看查询执行计划
db.users.find({name: "张三", age: 25}).explain("executionStats")
// 通过执行计划分析索引使用情况
三、特殊场景下的索引处理
有些特殊情况需要特别注意，就像开车遇到特殊天气要调整驾驶方式。
- 数组字段的索引
// 多键索引对数组字段的处理
db.products.createIndex({tags:1})
// 查询数组包含特定元素
db.products.find({tags: "electronics"})
// 注意：数组字段的复合索引有特殊限制
db.products.createIndex({tags:1, price:1})
// 这种索引在同时查询数组元素和价格时可能表现不佳
- 文本索引的特殊性
// 创建文本索引
db.articles.createIndex({content: "text"})
// 文本搜索查询
db.articles.find({$text: {$search: "MongoDB 索引"}})
// 注意：文本索引不能与其他索引类型混合使用
// 错误的复合索引：
db.articles.createIndex({title:1, content: "text"}) // 这种组合不允许
- 部分索引的应用
// 只为活跃用户创建索引
db.users.createIndex(
{name:1},
{partialFilterExpression: {status: "active"}}
)
// 查询时必须包含过滤条件才能使用索引
db.users.find({name: "张三", status: "active"}) // 使用索引
db.users.find({name: "张三"}) // 不使用部分索引
四、监控与维护索引健康
索引就像汽车需要定期保养一样，也需要持续监控和维护。
- 使用索引统计信息
// 查看集合的索引使用情况
db.users.aggregate([{$indexStats: {}}])
// 结果示例：
{
"name" : "name_1_age_1",
"accesses" : {
"ops" : NumberLong(1250), // 使用次数
"since" : ISODate("2023-01-01T00:00:00Z")
}
}
- 识别和删除冗余索引
// 查找可能冗余的索引
// 比如同时有 {a:1, b:1} 和 {a:1}，前者可以覆盖后者的查询
// 删除索引
db.users.dropIndex("name_1")
// 注意：删除前要确认没有重要查询依赖该索引
- 定期重建索引
// 索引可能因为碎片化而性能下降
db.users.reIndex()
// 注意：重建索引是阻塞操作，应在低峰期进行
// 对于大集合，考虑在副本集成员上逐个执行
五、总结与最佳实践
经过上面的分析，我们可以总结出一些MongoDB索引优化的黄金法则：
- 遵循ESR原则设计复合索引
- 让查询尽可能使用覆盖索引
- 定期审查和清理未使用的索引
- 对于特殊查询考虑使用索引提示
- 监控索引使用情况，及时调整
记住，索引不是越多越好。就像工具箱里的工具，关键是要有合适的工具，并且放在容易拿到的地方。每个额外的索引都会增加写入时的开销，所以要在查询性能和写入性能之间找到平衡点。
最后给个小技巧：在开发环境中使用explain()分析你的关键查询，就像给查询做体检一样，能帮你发现很多潜在的性能问题。生产环境则要定期检查慢查询日志，及时发现并解决索引相关的问题。
评论