By: Ami Levin

Ami Levin — Tue, 13 Sep 2011 13:24:20 +0000

Hi Reece,
Very good question, and like all good questions, the answer is simple
You are correct that the ProductID is not needed for this query.
The only thing that is needed from the SalesOrderDetail table is a list of all SaleOrderIDs. The optimizer has several options to get it:
1. Scan the entire table using a clustered index scan = retrieving huge amount of unnecessary data = unnecessary IO and unnecessary memory usage.
2. Get the IDs by scanning a non-clustered index. Since SalesOrderID is part of the clustered index (that supports the primary key), it is included in every non-clustered index and used as the row pointer.
There are two non-clustered indexes on the table, one on ProductID and one on RowGUID. ProductID is a 4 byte INT, RowGUID is a 16 byte unique identifier.
Which index would you scan?
The optimizer chose the smaller one and simply discarded the ProductID.
You can see this in the execution plan if you look at the properties of the index scan operator, you will see that the output list consists only of SaleOrderID.
Try to create a non-clustered index just on SalesOrderID and see how that changes the plan.

Ami

By: Reece

Reece — Tue, 30 Aug 2011 14:28:40 +0000

First, I want to say I am a developer. Second, I am trying to understand Query 8. Why did the Optimizer choose IX_SalesOrderDetail_ProductID when that field isn’t being used or returned? Does it have to do with the way the secret sauce of the HASH function? Meaning, it saw that was the best index to use for hashing?

Comments on: Physical Join Operators in SQL Server – Hash Operator

By: Ami Levin

By: Reece