So far, we've focused on the first two phases of tuning queries, identifying slow queries and then analyzing them. So now let's take a look at the third phase, optimization. Optimizing queries keeps your application fast, efficient, and scalable. This can save resources, cut costs, and result in higher user satisfaction. In this video, we'll use MongoDB Atlas Performance Advisor to optimize queries by adding indexes. We'll also cover indexing strategies for projections and expiring data, which will further enhance the performance of our queries. Let's get started. The MongoDB Atlas Performance Advisor is a tool available in m ten and higher clusters. It monitors and analyzes the queries executed in our database and provides actionable recommendations to enhance response times and efficiency. Some of its key features include index suggestions to enhance data retrieval speed, slow query identification, identifying unused indexes to find those that are consuming resources, schema recommendations for data modeling changes, and finally, query modifier suggestions to advise on how to refactor queries for better performance. Okay. Let's access the performance adviser. First, we need to log in to our MongoDB Atlas account. We select our cluster and then click here to go to the overview page. From here, we click the performance adviser tab. This takes us to the optimized performance page of the advisor. This is where the performance advisor provides suggestions for optimizing our queries. These recommendations are based on real time analysis of query patterns. In this case, we see that the performance advisor doesn't have any schema recommendations, but does recommend adding indexes to our cluster. This number tells us how many index recommendations it suggests. By clicking here, we can look at the specifics. On the create indexes page, the suggestions are listed in the order of impact. Each suggestion provides the name space for the recommendation, the suggested index structure, and metadata about the anticipated impact. Below the suggested indexes, we also see which indexes currently exist and the queries that will be directly improved by adding that particular index. By viewing the sample queries for each index, we can decide which of the indexes we want to create. Looking now at a sample query, we can see the query matches on the property type and room type fields and contains a range query on the number of nights and bedrooms. The query also includes a sort operation on the price field. From the suggested index metadata, we also know that the query scanned a lot of documents to get the results set. Let's go ahead and create this index and evaluate the improvements. The performance advisor makes it super easy to add a recommended index to our collection. It just takes the click of a button, the create index button here. This brings up a modal with the index information. By clicking review, we can then confirm that we want to build the index. The success model lets us know the index build is in progress. Depending on the size of the dataset, this may take a few seconds or several minutes. Now that we've created the index, we can test and evaluate the query by using explain. Let's run the query again in MongoSH. Wow. The query is now below the one hundred millisecond threshold. What an improvement. We can see that the query is now performing an index scan using the index we just created, and the execution time has dropped from multiple seconds to just a few milliseconds. Nice. Now what about queries that use a projection for the results? Remember that a query of a document in a collection in MongoDB returns all fields of each matching document. However, sometimes you only need specific fields from those documents. Using projection helps you achieve this. Projections can be optimized even further by using another indexing strategy to cover the queries completely. A covered query is one where all the fields required by the query, including filters, projections, and sort criteria are contained within an index. For example, this query filters equality matches to property type and room type, and it has a range filter on bedrooms. It also includes a projection for the listing name, and finally, it sorts by price. All of these fields are contained in this index. This means MongoDB can retrieve the data directly from the index, bypassing the need to access the documents. This reduces both disk IO and in memory data processing, speeding up query execution. Here's an example. This query filters on a variety of fields using equality and range filters. The query uses a projection to define which fields it will return and then sorts the results by price from highest to lowest. Looking at the explain output from this query, we can see that it took a long time to run. It examined over seventeen hundred documents, but returned just a few, and used a projection to limit the results to specific fields. Let's take each of the fields used in the query and create an index that covers the query. We'll start with the equality filters. Then we'll use price as the next item since it's used both as a range filter and for the sort. Then we'll use the other range filters and finish up with the projected fields. That gives us the create index statement seen here. Now let's create the index and run the query to see the improvements. I'll enter the create index command into mongo s h. Now that it's built, let's run the query with the explain command. This time, the query used the index. The projection was covered as seen here, and the execution time was in the single millisecond range, and zero documents were examined because the index covered all the data needed to satisfy the query. Well done. In this video, you learned how to optimize slow queries by using the MongoDB Atlas performance advisor. We covered how to access the performance advisor tab in Atlas and review its recommendations. We also explored how this tool makes it simple to implement index recommendations. Finally, we optimized a query that use a projection. Since we knew the exact fields required by the query, we built a covered index that retrieved the entire result set from the index itself. Great job putting all these strategies into action.