Comments on: Back To Basics: What’s the difference between a Scan and a Seek?

By: BrianTkatch

BrianTkatch — Thu, 24 Sep 2009 20:21:26 +0000

Thanx for the explanation. That was very helpful.

By: mrdenny

mrdenny — Thu, 24 Sep 2009 19:41:02 +0000

If you have an ORDER BY on your query then yes. If you don’t have an ORDER BY, then the SQL Server will probably sort by the clustered index and use it for filtering. If there is no clustered index it would then fall back to using the table itself and return the data in the order it comes across it.

By: BrianTkatch

BrianTkatch — Wed, 23 Sep 2009 13:06:19 +0000

Ah, but reading the INDEX is always preferred because of the ordering, if that is required?

By: mrdenny

mrdenny — Tue, 22 Sep 2009 21:26:52 +0000

Sort of. If the SQL Server decides that the most efficient method to access the data is a full table scan it will do so. If there’s no filter on the index, it’ll figure out which index to use to sort the index. If no index matches it’ll use the clustered index. If there’s no clustered index then it’ll use a table scan.

By: BrianTkatch

BrianTkatch — Tue, 22 Sep 2009 19:59:30 +0000

OK, sorting, interesting. Is there then an equivalent equation to

IF time-to-read-index + time-to-fetch-table > time-to-read-entire-table + time-to-sort THEN go directly to the TABLE; ELSE use the INDEX;

Or is it just use the INDEX unless the entire TABLE is requested?

By: mrdenny

mrdenny — Tue, 22 Sep 2009 18:51:37 +0000

You wouldn’t want to hit the table directly because the columns in the table probably aren’t sorted in the correct order. Without knowing that the columns are in the correct order the SQL Server will go to the index which is presorted and quicker to search.

By: BrianTkatch

BrianTkatch — Tue, 22 Sep 2009 13:59:43 +0000

“It is possible that it would, but not likely. The reason is that the table has other columns which you may or may not need in your query.”

Denny, thanx for responding. I want to learn this.

If the only COLUMNs being pulled are those on the INDEX, an INDEX anything would be faster because there’s less to read. But if other COLUMNs are used, it would have to hit the TABLE anyway. So, why not just go to the TABLE directly?

Isn’t it simple logic/math?

IF time-to-read-index + time-to-fetch-table > time-to-read-entire-table THEN go directly to the TABLE; ELSE use the INDEX;

Please expound on your comment. I have not got the point yet.

By: mrdenny

mrdenny — Thu, 17 Sep 2009 23:19:55 +0000

Brian,
It is possible that it would, but not likely. The reason is that the table has other columns which you may or may not need in your query. If there are a lot of other columns in your query the additional IO required to pull all those pages from disk, and then filtering them would almost always be slower then pulling a large number of records from an index.

Especially when you consider than an Index seek doesn’t need to load all the records of the index from disk. It only needs to load the needed pages from disk (based on the statistics) to get the information required.

By: BrianTkatch

BrianTkatch — Thu, 17 Sep 2009 13:05:02 +0000

Nice article.

Wouldn’t a table scan better after a certain amount of data is required from the table?

typo: “obsouly”
typo: “togo”

By: Mrdenny

Mrdenny — Mon, 24 Nov 2008 23:51:42 +0000

Your right, I somehow managed to get those backwards.

Thanks for pointing that out. I’ll get them in the correct order in just a second.