Full Table and Index Scan

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 41 minutes
Video Transcription
Welcome back to modulate. This is less an 8.4 full table and index scan. Now we have mentioned the full table scan before, but this lesson will be taking a closer look at it. In general, the full table scan as well as the full index skin are not good things, and you typically want to avoid them in your queries.
Now, just to go over that again, a full table scan is winning. Query has to examine all the records on a database table.
The common unintentional causes of Missing index. You may have a programmer or you yourself may have written a pretty good query, but there's no good index for that query. In such a case, it might warrant creating an index on that table to solve that problem.
Now the common intentional cost is a program needs all records for processing. For some reason,
one example might include a state table that only has 50 records, and we don't really expect that table to grow that much. It's it would be a reference to the United States, and we don't expect the United States to begin adding dozens or hundreds of records that represent different states.
However, such scenarios are unusual, and sometimes you do want to look into him to make sure that the context of that table makes sense, or the context of that query makes sense.
Now moving on the full index scan, the performance is actually worse than a full table scan.
You will want to drop the index to use a full table scan if is needed. For example, if you want to select all your employees and your selecting where employee I D is greater than zero because you know that's a clever way to do it. Well, you'd actually want to remove that reference or that filter
and just let the full tables can occur.
And this is because the full index scan has performance that is worse than the full table scan because there is some computational weight related to check in the index. So if the database engine needs to check every record against the index, that's going to take longer than just doing the full table scan.
So if you do have a reason to do a full table scan,
you do want to make sure that you are not doing a full index can as the performance is worse. Now. With that, let's go ahead and jump into the development environment and take a look at some examples.
All right, here we are at the development environment. I have three queries on the script. The pain. The top query is a reference to the system that statements with full table scans view that we discussed in a previous lesson. So if I run that query, I'll see a list of queries that useful table scans.
So you can use this to check what kind of queries are running against your database. They're using full table scans
now. If you look through this and you do see the use of the limit question mark a lot, Where that's coming from is actually when you type in how many records you want and D beaver Deep Beaver automatically appends that limit that limit and that amount to your queries that you run. So that's where that's coming from.
In case you were curious about that.
Now, moving on, we take a look at this Cleary. We'll take a look at the Data Day returns.
We see that it's using the company i d. The Tran type and the reference number.
We go look at the table architecture.
We'll see that the PM Tran UK one references those columns so it looks like the programmer might have attempted to use the index. But if we use the explain command to look at the execution plan for this query,
we'll see that it's of type all which means that it's doing a full table skin, and the index is not being used, though at first glance you might believe the index is being used. Now, how can we resolve this? Well,
the first thing I would do is get rid of this reference number is like a wild card because this is simply saying I want every
record back. I don't care what the reference number is. Well, if you don't care what it is, you simply get rid of that.
So now we have the two. The two columns of that composite key or that composite index, So we're actually missing one now. We don't have
reference number, So if we run, explain again,
we'll see that we're still doing a full table scan.
So how do we fix this? Well, this is where we can actually use one of those commands to force the use of an index. We can see that the execution plan is indicating that there are possible keys so we could use the PM Tran underscore UK one key,
which is that key that we're looking at The execution plan decided not to use it because we didn't have a referenced all the columns there.
Well, we can force it to use it.
And again, you want to make sure you get the syntax right here, So this will go above the filters. So we're gonna type in the keyword force
um, the brackets, and then we need to copy
that key name.
So if I paste it in there, I'm gonna delete the other one because I just want to use this one,
and I run the explain command again.
Now, we changed to type reference, which is a lot better, and we're still returning a lot of rose. But if you actually go and look at the data,
that's actually about the number of rows that we need to return anyway, Based on that query, because a lot of them are of trans I p m.
Okay, so moving on to take a look at this query, you might initially think that it's a full table scan,
but if we do and explain
and we run that will see that it's actually of type Index and were returning. All the records are all the roads, so it is a full index skin.
So how would we fix this query?
Well, if that is indeed what we want, which would actually be very dangerous on a transaction table. But if that is indeed what we want, all we have to do is get rid of the order by
now. If we take a look at it and we run the explain command again, we'll see. That is now a full table skin.
So with the first query, it was doing a full table scan. But we, however, revised it to correctly use an index.
And with the second query, we changed them from a full index scan to a full table scan.
So let's go ahead and head over to the summary before we close out the lesson.
So that brings us to the 8.4 summary. So what did we discuss in this lesson? Well, we looked at examples off the full table scan as well as an example of a full index can now full table scans are when all records are examined by the database engine, you can resolve them by index targeting.
We can use a command to force index use if necessary, which is what we did. In the example.
We used the command force index toe force the database engine to use the index that we indicated.
Now we also looked at a full index. Can you can switch these two a full tail scan if all the results are actually necessary?
And if not, you could switch your index use
just like we did in the full table scan example
now in general. And this is worth repeating. You want to avoid both the full table and the full index scans whenever possible. It is a common problem found in the field,
so that completes this lesson, and I hope to see in the next Thank you
Up Next