Indexesmedium3-5 years

A session-token collection needs to expire tokens automatically after 30 minutes of inactivity, and a separate `orders` query needs a fast, small index for `status = "OPEN"` orders only, out of a collection that's 99% `CLOSED`. What index type solves each, and why wouldn't a plain index work as well for either?

A TTL index on a date field (lastActiveAt) expires a document N seconds after that field's value — the server runs a background task that deletes expired documents on its own, so the session collection self-cleans with no cron job or application-level cleanup code needed. A plain index on the same field would let a query filter or sort by it efficiently, but it does nothing to remove old documents; something would still have to run a deleteMany on a schedule. For the orders index, a partial index built with partialFilterExpression: { status: "OPEN" } only indexes the 1% of documents that are actually open, which makes it far smaller and cheaper to maintain than a plain index on status covering all the closed orders too — a plain index would faithfully index every CLOSED order as well, paying storage and write cost for values the query never asks for.

The lesson behind it →

PreviousA hot endpoint runs `db.orders.find({"customer.id": id}, {_id: 0, "customer.id": 1, placedAt: 1, orderNumber: 1})` against an index on `{"customer.id": 1, placedAt: -1}`, expecting a covered query. `explain()` shows `totalDocsExamined` equal to the number of documents returned, not zero. Why isn't it covered, and what's the actual aggregation-pipeline cost of joining in the order's line items afterward?Next A service writes an order with `w: "majority"` then immediately reads it back from a secondary with `readPreference: "secondary"` to confirm it was saved — and sometimes the read comes back empty. The write concern was already majority; why does the read still miss it, and what actually fixes it?