The scan is the optimal choice because all rows are needed. There are no predicates (filtering conditions) that could be used to seek.
You can turn any index scan into a (meaningless) index seek by adding a predicate that covers the whole index, for example:
...but this would be pointless, and counter-productive. A seek can be useful if it helps reduce the number of rows returned by a data access operator, but a seek that returns the same rows a scan would is simply less efficient. Many people new to SQL Server fall into the trap of thinking a seek is always better than a scan; this is not so.
There are some small improvements I would make to your query:
With those in place:
You may notice a small increase in efficiency by performing the arithmetic on the result of the aggregates rather than on every row before it is aggregated.
By SQLkiwi ♦ 6.6k answered May 12, 2016 at 12:37 AM