SELECT TOP ist langsam, unabhängig von ORDER BY

Und so beginnt das unglückliche Spiel des „Versuchs, den Optimierer auszutricksen (weil er es nicht immer am besten weiß)“.

Sie können versuchen, die Filterteile in eine Unterabfrage oder einen CTE zu packen:

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

Was ausreichen kann, um es zu zwingen, zuerst zu filtern (aber der Optimierer wird mit jeder Veröffentlichung "klüger" und kann manchmal solche Spielereien durchschauen). Oder Sie müssen möglicherweise so weit gehen, diesen Code in eine UDF . Wenn Sie die UDF als Tabellenwertfunktion mit mehreren Anweisungen schreiben, mit der Filterung darin, und diese UDF dann mit Ihrem TOP x abfragen /ORDER BY , haben Sie die Abfragereihenfolge ziemlich gut erzwungen (weil SQL Server derzeit nicht in der Lage ist, UDFs mit mehreren Anweisungen zu optimieren).

Wenn man darüber nachdenkt, ist die Einführung der UDF natürlich nur eine Möglichkeit, zu verbergen, was wir wirklich tun - eine temporäre Tabelle erstellen, eine Abfrage verwenden, um sie zu füllen (basierend auf WHERE-Filtern), dann eine weitere Abfrage, um den TOP x aus der temporären Tabelle.