MongoDB中db.collection.count()与db.collection.count({})计数不一致问题

Let me break down why you're seeing this 300k discrepancy between the two count calls—this is a common gotcha with MongoDB's older count methods, especially if you're using a version before 4.0 (though even newer versions have legacy behavior to watch out for).

Key Differences in How the Two Calls Work #

• db.collection.count() (no arguments): This method relies on metadata-based estimates from the storage engine (like WiredTiger's internal statistics) to return a count quickly. It doesn't actually scan every document or even check for deleted documents that haven't been cleaned up yet (these are called "ghost documents"). The tradeoff here is speed over precision.
• db.collection.count({}) (empty query): This performs an exact count by either scanning the entire collection or using an available index to tally documents. It excludes any ghost documents—documents that were deleted but haven't been fully purged by WiredTiger's background cleanup process. This is slower but accurate for the current set of active documents.

Most Likely Causes for Your Discrepancy #

1. Uncleaned Ghost Documents
   WiredTiger uses a lazy deletion strategy: when you delete documents, they're marked as deleted but not immediately removed from disk. The storage engine cleans these up in the background during periods of low activity. Until that happens, count() (no args) still counts them in its metadata estimate, while count({}) ignores them because it's checking actual document existence.

2. Sharded Cluster Metadata Drift
   If your collection is in a sharded cluster, db.collection.count() pulls counts from each shard's metadata, which can become outdated if shards haven't updated their stats recently. db.collection.count({}) sends a query to each shard to get an exact count, so it reflects the current state of each shard's data.

3. Legacy Method Behavior Changes
   MongoDB 3.2 introduced changes to the count() method's behavior to align with how queries work. Before that, count() and count({}) were more similar, but post-3.2, the no-arg version prioritizes speed via estimates, while the empty query version prioritizes accuracy.

What You Should Do Next #

• Use Modern Count Methods: MongoDB has deprecated the legacy count() method in favor of two clearer alternatives:
  • db.collection.estimatedDocumentCount(): Replaces db.collection.count()—gives a fast, metadata-based estimate (same as the old no-arg count).
  • db.collection.countDocuments({}): Replaces db.collection.count({})—gives an exact count by scanning documents or using an index.
• Force Ghost Document Cleanup: If you want to reconcile the counts immediately, you can run db.collection.compact() (note: this locks the collection and should be done during maintenance windows) to trigger WiredTiger to clean up deleted documents.
• Verify Shard Stats: For sharded clusters, run sh.status() to check if shard metadata is up to date, and consider refreshing stats with db.collection.stats() on each shard.

Pro Tip: Always use countDocuments() when you need an accurate count of active documents, and reserve estimatedDocumentCount() for cases where speed is more important than perfect precision.

内容的提问来源于stack exchange，提问作者Naga Sai Kiran Pesaralanka