_ч_,

Теперь стало понятнее в чем дело.
Дело не в представлении, а в том, что вы указываете разные порядки сортировки, при том, что к сожалению, свойство сортировки имеет ограничение на распространение на нижние операторы.
Попробуйте выполнить запрос, без view:


Вы увидите точно такой же план:


Если обратите внимание, то сканирование не упорядоченное, а сортировка по двум полям, одно то, которое вы указали явно - processed, другое - ключ кластерного, которое, вы нигде не указывали.

Откуда требование ко второму ключу.
В этом виноват оператор Merge Join (Concatenation), который требует чтобы строки к нему поступали в отсортированном порядке. А т.к. выбираются все строки, то чем делать сортировку по многим столбцам, проще сделать сортировку по одному уникальному столбцу кластерного индекса и первичного ключа.

В одиночном запросе


Merge - нет, требований к сортировке по ID нет.

Если сделать индекс покрывающим (в данном случае, я просто поменяю запрос, для простоты):


То план будет:


Т.е. сортировка обеспечивается сканированием в обратном порядке.
Теперь, добавим поле name в запрос:


Снова план:


Но на этот раз, участвует колонка name.
Если добавить ее в индекс как ключевую колонку, чтобы обеспечить сортировку:


План:





В чем состоит ограничение.
Хотя нигде явно требования по сортировке в порядке возрастания колонки ID asc не указано, оптимизатор, виду ограничения распространения свойств сортировки не рассматривает вариант ID desc при вычислении свойств сортировки сканирования.
На эту тему есть item MS Connect заведенный Steve Kass.
Query optimizer misses optimal ORDERED BACKWARD plan unless query includes ORDER BY.
Который, к сожалению, закрыт как Closed as Won't Fix .
Объяснения от MSThis is due to a known limitation of sort property propagation. I would like to address this when Yukon SP3 work starts in earnest, but we'll see, since it's significant effort.
Но воз и ныне там =)

Что можно сделать
1. Явно определить порядок сортировки ключа кластерного, что приведет оптимизатор к backward scan и избавлению от сортировки:



2. Если реальные данные позволяют, сделать индекс уникальным, тогда у оптимизатора отпадет необходимость включать в сортировку ключ кластерного чтобы обеспечить сортировку строк.



3. Добавить в некластерный ключ кластерного с явной сортировкой



Все три приводят к плану:


В целом, досадное упущение оптимизатора. Я смотрю вы тоже завели Item на коннект. Публикуйте его сюда, пусть люди голосуют, авось пофиксят =)