Yes, your index would be the best one for this query according to the ESR rule. The trade off is that more index keys will need to be scanned as some documents will be picked up from the index (but sorted!) and then eliminated by the range query at the end.
The fact that you pick the index entries sorted and THEN remove some of them afterwards allow you to avoid the in-memory sort that would be required otherwise to solve this query.
Basically, with this index, you get the sort for free. You can confirm this by running an
.explain(true) on it.
The index a,b,c,d,e,f would be more selective (less index entries would need to be scanned. But they aren’t sorted by e & f anymore before of the range query before them.
The best representation that I found for this is to imagine something like this. Let’s say my use case is find name = bob & age > 12 sorted by size.
I imagine I’m in a room. In this room there are big cupboards => one for each name (Alice, Bob, Maxime, …).
In them, I have large boxes. One for each age. And in each of these boxes, I have little folders, sorted by size.
If I take name = Bob, I go to the cupboard with Bob on it. Then if my index is (name, age, size), I need to take all the large boxes in it with age > 12… And to finally answer the query I need to take all the folders in all these boxes that aren’t sorted all together… So I need to manually sort them
If you change the index order to (name, size, age) you can just pick the docs from the folders and pile them up in order as they are already ordered by size if you pick the boxes in the right order ;-).
I hope this helps a bit.