Questions regarding the $in operator and compound index, also need advice

Hello, I am fairly new to MongoDB and recently studied compound indexes. To be precise, the ESR rule. And I have a couple questions about using the $in operator.

According to the docs, $in acts as an equality operator when used alone. And it acts as a range operator when used with sort. I have to build a compound index for a filtering search where I have multiple attributes which I have to check for exact matches (can be multiple values) and also sort them according to the time when the document was created (so a lot of unique values). I did not know about the $in acting different in different scenarios before and assumed it is an equality operator every time. And hence created the following index:

{field1: 1, field2: 1, field3: 1, created_at: -1}

So my queries look kinda like this:

'field1': { $in: ['example1', 'example2'] },
'field2': { $in: ['example1', 'example2'] },
'field3': { $in: ['example1', 'example2'] }
}).sort({'created_at': -1})

Since not all fields are passed in by the user, in order to make my compound index cover the query, I put in all the possible values in the $in array in case a field is missing. My array size does not exceed 300.

The query given above, uses the index { created_at: -1 } instead of the compound index I created. I assume this is because using the compound index means the mongo will have to apply an in memory sort, which is undesirable if I am not wrong and hence the query planner goes ahead with the other index. Now my course of action to correct this would be to follow S => R and creating this compound index:

{created_at: -1, field1: 1, field2: 1, field3: 1}

This means all the fields which I am using for exact matches now become range operators. My question is, is there a better way to do this? Should I be using the $in operator here, instead of say, $or? And is this even a way to correctly do it in the first place? I am losing the E out of ESR and my concern is also that since created_at will have a lot of unique values, won’t traversing a compound index with created_at at the beginning take a long amount of time?

Few points to be kept in mind:

  1. The collection contains over 3 million documents.
  2. I will always have to sort the documents returned using the created_at attribute.