SQL Server Execution Plans - Red Gate Software

Chapter 2: Graphical Execution Plans for Basic Queries
If we change the query as shown in Listing 2.11, we get the execution plan shown in
Figure 2.29.
SELECT *
FROM Production.ProductInventory
ORDER BY ProductID
Listing 2.11
Figure 2.29
Although this query is almost identical to the previous query, and it includes an ORDER
BY clause, we don't see a Sort operator in the execution plan. This is because the column
we are sorting by has changed, and this new column has a clustered index on it, which
means that the returned data does not have to be sorted again, as it is already sorted as a
byproduct of being the clustered index. The query optimizer is smart enough to recognize
that the data, as retrieved through the index, is already ordered, and does not have to be
ordered again.
If you have no choice but to sort a lot of data, you should consider using trace events,
Performance:Showplan XML, to see if any Sort Warnings are generated. To boost
performance, SQL Server attempts to perform sorting in memory instead of on disk,
since sorting in RAM is much faster than sorting on disk. However, if the Sort operation
is large, SQL Server may have to write data to the tempdb database and sort on disk.
Whenever this occurs, SQL Server generates a Sort Warning event, which we can
capture using trace events. If your server is performing many Sorts, and generating many
Sort Warnings, then you may need to add more RAM to your server, or to speed up
tempdb access.
102