SELECT TOP è lento, indipendentemente da ORDER BY

E così inizia lo sfortunato gioco di "cercare di superare in astuzia l'ottimizzatore (perché non sempre conosce bene)".

Puoi provare a inserire le porzioni di filtro in una sottoquery o CTE:

SELECT TOP 30 *
FROM
   (SELECT *
   FROM myview, foo, bar 
   WHERE shared=1 AND [joins and other stuff]) t
ORDER BY sortcode;

Il che potrebbe essere sufficiente per forzarlo a filtrare prima (ma l'ottimizzatore diventa "più intelligente" ad ogni versione e talvolta può vedere attraverso tali imbrogli). Oppure potresti dover inserire questo codice in un UDF . Se scrivi l'UDF come una funzione con valori di tabella multiistruzione, con il filtro all'interno, e quindi esegui una query su quell'UDF con il tuo TOP x /ORDER BY , hai forzato abbastanza bene l'ordine di query (perché SQL Server non è attualmente in grado di ottimizzare le UDF con istruzioni multiple).

Ovviamente, a pensarci bene, l'introduzione dell'UDF è solo un modo per nascondere ciò che stiamo realmente facendo:creare una tabella temporanea, utilizzare una query per popolarla (basata sui filtri WHERE), quindi un'altra query per trovare il TOP x dalla tabella temporanea.