Challenge 1: Diagnose a Profiler Entry — Possible Solution
====================================================================

THE FIX: create an index on the email field.

db.users.createIndex({ email: 1 })

BEFORE (no index), running explain() on the same query would show:

  - stage: "COLLSCAN" — a full collection scan, meaning MongoDB had to
    examine every single one of the 2 million documents to find the
    ones matching that email.
  - totalDocsExamined would be close to 2,000,000 — nearly the entire
    collection — even though the query only ever returns at most one
    or a handful of matching documents.
  - executionTimeMillis would be high, and would keep growing as the
    collection grows, since a collection scan's cost scales with total
    document count regardless of how selective the actual query is.

AFTER creating the index, explain() would instead show:

  - stage: "IXSCAN" — an index scan, using the new index on email to
    jump directly to matching entries instead of scanning everything.
  - totalDocsExamined would drop to roughly the number of ACTUAL
    matches (typically 0 or 1 for an email lookup), regardless of how
    large the collection grows.
  - executionTimeMillis would drop dramatically and would no longer
    scale with collection size the way a collection scan did.

This is exactly the mongodb1-7 diagnostic workflow (COLLSCAN vs IXSCAN,
totalDocsExamined) applied to a real slow query the profiler surfaced,
rather than one already suspected in advance.