In our slow query logs we can see that this query below is using the incorrect index which causes it to run slowly.

[conn3522] command haa_msgs.$cmd command: count { count: "messages", query: { $or: [ { targetId: ObjectId('55fc54eecb05d8d2547334a1') }, { targetId: null } ], type: { $in: [ 2 ] }, createdAt: { $gt: new Date(0) } }, fields: null } planSummary: IXSCAN { createdAt: -1.0 } keyUpdates:0 writeConflicts:0 numYields:271 reslen:44 locks:{ Global: { acquireCount: { r: 544 } }, Database: { acquireCount: { r: 272 } }, Collection: { acquireCount: { r: 272 } } } 103ms

We have an index on this collection that I would expect to be used. But the log implies it uses a different index to run the query.

{targetId:1, type:1, createdAt:-1}

However, if I manually run a find query using the same query conditions, the explain plan uses the expected index.

This type of query has always behaved as expected in the past. This problem occurs on version 3.0.4 and 3.0.6.

Not sure what is going on here, but this is causing serious performance problems in our database.