Why Are Table Scans Bad?

Question

At my work, I am often told that I shouldn't do a table scan because it could negatively impact the database and the app using the database. What exactly do they mean by "negatively impact"? One negative impact I can think of is that a table scan would use up a lot of the disk's time, blocking other requests from using the disk.

Is there a way to do a table scan without any negative impacts? Sometimes I need to do a table scan for one off checks (for routine things, I would of course make an index).

Answer 1

Table scans are not evil per se, it depends on what the query is supposed to do. If a large portion of the table is either returned to the application or used in some aggregate (like sum), it is probably most efficient to do a table scan.

If on the other hand, a small percentage of the table is to be used, looking up the rows via an index is much more efficient.

A scan uses disk resources as you mention. Another effect is that cached data in memory might have to be flushed to make room for the scan. I.e. applications may have to read data from disk instead of memory due to unnecessary scans.

Answer 2

Why are Table Scans bad?

Task: I give a book and ask you to list the page numbers where the word "artichoke" appears on that page.

How can you do this? You going to have to read the whole book.

While you're reading that book, you can't be reading any other books, for anybody else (at least not easily).

• If the book is only two pages long, you can probably do that fairly quickly.
• If it's 1000 pages long, it's going to take you a while.

If the book were about Gardening, then you might have an Index at the back that listed particular vegetables and the pages on which they were mentioned. That would make you task a lot easier.

In the database world:

• "Reading" is [often] pulling pages from disk,
• Trying to read other books (which databases can do) is the contention on the Buffer Cache, where all of the data "lives", and
• Indexes are, well, indexes.