Why this problem matters
Recurring COLLSCAN on large collections can increase CPU and storage reads. A collection scan may still be reasonable for small collections or queries requesting most data.
How to diagnose it
Inspect the representative query's winningPlan tree for COLLSCAN and review execution counts. Interpret it with collection size, selectivity, and call frequency.
The example changes no data and requests limited results. Use the real query shape because production selectivity may differ.
db.orders.explain("executionStats").find({status: "pending"}).limit(20)A safe solution approach
Test a suitable index candidate when the query is frequent and selective. For rare administrative queries, also account for the write and disk cost of another index.
Why continuous monitoring matters
Continuous monitoring catches new collection scans after deployments. moon monitors with low overhead and can provide Slack, PagerDuty, or webhook alerts.
Frequently asked questions
Should every COLLSCAN receive a new index?
No, scan cost depends on query frequency and collection size. Measure the new index's write and storage cost as well.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.