A full table scan looks throughall of the rows in a table – one by one – to find the data that a query is looking for. Obviously, this can cause very slow SQL queries if you have a table with a lot of rows – just imagine how performance-intensive a full table scan would be on a table with millions of rows. Using anindex can help prevent full table scans.
Let’s go through some different scenarios which cause a full table scan:
Normally, statistics are kept on tables and indexes. But, if for some reason table or index statistics have not been updated, then this may result in a full table scan. This is because most RDBMS’s have query optimizers that use those statistics to figure out if using an index is worthwhile. And if those statistics are not available, then the RDBMS maywrongly determine that doing a full table scan is more efficient than using an index.
If a query does not have a WHERE clause to filter out the rows which appear in the result set, then a full table scan might be performed.
There are some scenarios in which a full table scan will still be performed even though an index is present on that table. Let’s go through some of those scenarios.
If a query does have a WHERE clause, but none of the columns in that WHERE clause match the leading column of an index on the table, then a full table scan will be performed.
Even if a query does have a WHERE clause with a column that matches the first column of an index, a full table scan can still occur. This situation arises when the comparison being used by the WHERE clause prevents the use of an index. Here are some scenarios in which that could happen:
Would you like to thankProgrammerInterview.com for being a helpful free resource?Then why not tell a friend about us, orsimply add a link to this page from your webpage using the HTML below.
Link to this page:
Please bookmark with social media, your votes are noticed and appreciated: