welcome back to modulate. This is less than 8.3 examined. And this lesson we're gonna take a look at some common index problems, and these include unused indexes, duplicate indexes and missing indexes were gonna look a query. Optimization is with explain to identify missing indexes.
And here are some things to avoid
with respect to indexes. You want to avoid using an index when the majority of table records will return. Now this is somewhat subjective,
but the use of an index becomes expensive, the more records you return. And that's because the database engine actually has to do some extra computation every time it examines the index. So not examining the index when a great majority of the records coming back well actually will actually
Now the cut off point is a little bit subjective, but usually study 5% is a good 75% and upward is a good time to start considering not using the index. So if you have a table of ah 100 records and you are going to write a query that's going to return 80 records,
you may not want to use an index. In that case,
index use case strengthen as record return count decreases So the best case foreign indexes when you're returning one record
and excuse case weakens as record return count from the table increases. So the worst case of when you want to avoid an index is when you're gonna return every record from the table. If you're gonna bring back every record from the table, there's no need to use an index
now. That said, let's go ahead and jump into the development environment and take a look at what this looks like.
Here we are, the development environment. I have three queries on the script pain that are all selecting from thesis database. Now the system a base is a database that gets installed with my sequel, and it contains a table and a lot of views
that helped really diagnose potential problems in my sequel and provide a lot of useful information on your database.
Now there are more views than we can go through. As you can see on the left hand side, there are a lot of views,
but we're going to focus on three that will provide useful information related to our index problems. So if I run the first query, which is skim on used indexes.
It'll give us a list of unused indexes. So these air indexes that might be safe to remove from our database and remove that unnecessary index weight from our database engine.
However, there are some scenarios in which it unused index. It might make sense in one such scenario, perhaps a table was just recently created, and nothing's been written that uses the index yet, although it is planned down the road for later.
So in that scenario, you wouldn't want to remove the index now. On the other hand, if you're looking at a table that's been unchanged for three years and it has unused index is, well, very well could be safe to remove those indexes.
if we select from skim a redundant indexes,
we'll see a list of indexes that are mentioned more than once on table definitions. And in a lot of cases, you might see a composite key that contains a index as well as an index by itself. And sometimes that's done so that the my sequel, OPTIMIZER, will automatically select that index
without the need to manually select the index.
So again, depending on the context, a duplicate or redundant index could make sense.
However, again, if you know that the table has a redundant index, that's been instead, she aided by accident. It should be safe to remove
the way that we would find missing index as we would select from statements with full table scans. So these are going to be queries that in Stan Shih ated a full table scan when running.
So if I select from that,
we can see the queries that have been run against the database on, we can see that these are the queries that required a full table scam.
So depending on what is going on, you could identify. You could use this to identify and missing index. Or you do have to be careful because it could be a programmer. That's just writing some weird queries. They don't really warrant the creation of in an index. So you do have to kind of look at this and identify what's going on
and if there is a place to optimize by introducing a new index.
So these are These have been three views that help you identify different problems with indexes and are useful when trying to optimize your database.
Now let's go ahead and head over to the review before we close out this lesson.
And that brings us to 8.3 summary And this lesson. We discussed the cyst database, which is installed when my sequel is installed.
This database contains many views with useful diagnostic information. In fact, it contains too many views to go over. But we did go over three related to identifying possible problems with index is the 1st 1 was the system that skim a unused indexes. This contains a list of database indexes that have never been used.
Next on the list is this system skim a redundant indexes, which contains a list of duplicate in Texas.
And finally we had sister out statements with full table scans, which contains a list of queries that enacted a full table scan to complete.
Now, something to keep in mind when looking at this data is that sometimes it's some scenarios or some context makes sense for such an item to exist,
for example, and the unused index, it's possible that you have a new database table with new indexes that isn't in the process of being designed, so it's never been used. And that makes sense.
An example of full table scans. You might have a programmer who is simply testing out new queries and isn't too concerned with indexes, and you may not want to go out and try to create indexes to facilitate his experimentation.
Now, with that said, that completes this lesson, and I hope to see in the next thank you.