The execution plan generated for certain $or queries is amendable:

> db.domain.ensureIndex(

{ key: 1 }

)
> db.domain.find( { $or: [
{ key:

{ $gte: 722156315770, $lt: 722156332548 }

}, { key:

{ $gte: 722156333548, $lt: 722156349325 }

}, { key:

{ $gte: 722156416434, $lt: 722156433211 }

},
{ key:

{ $in : [ -922337203685477, -230584300921369, -154023107256070, 115292150460684, 153726349067734, 461172215037663 ] }

}
] } ).explain();

===>

{ clauses: [
{ cursor: "BtreeCursor key_1", ..., indexBounds:

{ key: [ [ 722156315770, 722156332548 ] ] }

},
{ cursor: "BtreeCursor key_1", ..., indexBounds:

{ key: [ [ 722156333548, 722156349325 ] ] }

},
{ cursor: "BtreeCursor key_1", ..., indexBounds:

{ key: [ [ 722156416434, 722156433211 ] ] }

},
{ cursor: "BtreeCursor key_1 multi", ..., indexBounds:

{ key: [ [ -922337203685477, -922337203685477 ], [ -230584300921369, -230584300921369 ], [ -154023107256070, -154023107256070 ], [ 115292150460684, 115292150460684 ], [ 153726349067734, 153726349067734 ], [ 461172215037663, 461172215037663 ] ] }

} ],
...
}

This is according to the docs but slow, nonetheless. I would expect the following plan

{ cursor: "BtreeCursor key_1 multi", ..., indexBounds:

{ key: [ [ -922337203685477, -922337203685477 ], [ -230584300921369, -230584300921369 ], [ -154023107256070, -154023107256070 ], [ 722156315770, 722156332548 ], [ 722156333548, 722156349325 ], [ 722156416434, 722156433211 ], [ 115292150460684, 115292150460684 ], [ 153726349067734, 153726349067734 ], [ 461172215037663, 461172215037663 ] ] }

}

Which would almost halve the execution time (measured against a modified mongod where I patched the optimizer).

Instead of modifying the optimizer, an alternative could also be to extend $in to accept ranges as well.