If I write a query and filter results using $where on an indexed field, will it use the index or will it scan into each document? For example?:
function () { return this.indexed_field > 5 }
..and yes I'm well aware I could get away with using $gt in this particular instance =)
No, an index won't be used in that case. You can run an explain() to verify.
Related
I am using mongodb 3.2.4
When I execute db.mytable.find().explain() The winning plan is 'Collscan'
But when I execute db.mytable.find().hint(_id:1).explain() The winning plan is 'IXscan'
So here comes a question: since _id is the default index of a table, why mongodb does not use this index to query?
An index can be used when there is a filter criteria or a sort operation - when the fields in the index are used in the filter predicate and/or the sort. In your case, the find method doesn't have a filter criteria or a sort - so no index is used, and you can see that in the query plan as a collection scan. It is as expected. But, when you provide a hint to the find method the query optimizer tries to use the index, and in your case it did (and you see it in the query plan as an IXSCAN). In either case, with or the without the hint, the find has to scan all the documents or keys in the index.
The _id has a default unique index, yes, but unless you are using the _id field in the query filter predicate or in a sort, the query cannot use it (or, specify explicitly to use index with a hint). You can verify with the following queries, db.mytable.find( { _id: 123 } ) or db.mytable.find( { } ).sort( { _id: -1 } ) the query planner will show index scan even though you do not specify the hint.
The main purpose of the indexes is to make your queries run fast; it is about query performance. It has to be a query with filter predicate and/or a sort operation to use an index (and the fields used in the filter or sort must be indexed for performance). With the find method, in your case, without any of the two you are just accessing all the documents as they are in the collection and the index is of no use (and the query optimizer shows that in the plan).
I have a collection product in my DB. Below is one sample document:
{
"sku_id":"12345678",
"priduct_name":"milk",
"product_rank":3,
"product_price": 2.4
}
There are 100k such unique documents in our collection.
I want to query this collection using $in query, as shown below.
db.product.find({"sku_id" :{$in :["12345678","23213"]}}).sort( { product_rank: 1 } )
Our requirement is to search documents based on $in query and sort any field in document(asc or desc).
I have created both forward and reverse index on all fields for this collection.
Note: This sku_id array inside $in query can have 1000+ sku_ids.
My doubt is if I use the filter like $in with an array of sku_id and get the sorted result on any field, will it use the index for sorting or will it sort at query time?
Mongo allows you to find out if a query will use an index. As the find operation returns a cursor you can extend the method chain to include an explain() command which does exactly what you need. (suggest you use db.product.find(...).sort(...).explain('executionStats'))
Will it use the index for sorting or will it sort at query time?
The index created on the product_rank will be used in the query but, not an index on the sku_id alone. Instead create a compound index with both product_rank and sku_id(asc and desc).
Is there any way to force a find() or aggregate() query to refer/see a particular existing index in MongoDB. I am asking about the the scenario when a collection has more than one compound indexes.
Yes, $hint is there for that. As mentioned in the documentation, you can use it like that:
db.users.find().hint( { age: 1 } )
What you put in argument is the definition of the index, and not its name. This query would force the use of the index on the age field. I'm not sure though whether it works for aggreate() call as well or not.
Aggregation does not support $hint. There is a open item in MongoDB
https://jira.mongodb.org/browse/SERVER-7944
I believe they both return the same results, but essentially which is one is better to use under what scenarios?
Here is what the documentation says:
Returns the count of documents that would match a find() query. The db.collection.count() method does not perform the find() operation but instead counts and returns the number of results that match a query.
There's no difference. One is implemented in terms of the other:
> db.users.count
function ( x ){
return this.find( x ).count();
}
From my understanding, they are equivalent to each other. db.collection_name.count() does not use the find() function, therefore, I would assume that it would be slightly better performance wise.
Check out the official MongoDB page referencing this.
MongoDB Count
Hi how can check what index use , and number of scanned objects in aggregate query , something similar to
db.collection.find().explain() ?
Right now, there is no explain functionality for aggregate() yet. However, in general indexes are only used for certain operators if they are the first element in the aggregation operator pipeline. For example, $match and $geoNear.
So in order to figure out which index is being used, simply run the explain() on a find() where the query matches your first $match options.
explain() functionality for aggregate() is an issue in JIRA: https://jira.mongodb.org/browse/SERVER-4504 — I would suggest you vote for the issue on JIRA as well.