1. The most important thing, generally, to look at is whether the operations being performed are what you think should be performed. Are any indexes being maintained that you think are unnecessary? Is an index being ignored? If there are multiple steps in a query (perhaps this was a batch of statements, or a stored procedure) look first at the one that consumed the most time - this is reported as a percentage. Concentrate your efforts on improving the subtrees that consumed the most time. 2. These are the operations being performed. The SELECT operator returns the rows returned by the operations to its right to the client - as such it doesn't add very much overhead at all. TOP guides the operations to the right to stop once the given number of rows are returned. A Hash Match[^] is a way of performing a join, useful if there are a lot of join conditions. The server builds a hash table for both the left and right sides and compares the hash values to determine if there's a match. The Left Anti Semi Join[^] means that rows that are in the first but not in the second are returned - your query probably uses NOT IN, or similar. Hash matches tend to be used if no suitable index was used. If a suitable index is available, and the number of rows to be returned is small, SQL Server will normally use nested loops with an index seek to find rows in the second table. 3. An Index Scan is where SQL Server starts at the beginning of the index and reads every row, to the end, looking for rows that match. Compare this to an Index Seek, where SQL Server looks directly for a particular value by looking in the right place. It's the difference between looking for an entry in a phone book by starting at the beginning and looking at every page, and looking instead for the first letter, then the next letter, etc. a) This is the number of rows that were actually returned by this operator. b) This is how big each
