Dave62 (10/21/2011)
SanDroid (10/21/2011)
...I should have been more specific in my question.Does using a "TOP 99999999" statement with an "order by" in a VIEW against an actual table with less than 99.9 Million rows keep the query optimizer from ignoring the Order by statement since nothing will be filtered?
I know in a basic select with a variable it will not, but Views are different. 😎
I think it does. Give this a shot.
USE [AdventureWorks];GO .......
May need more testing though.
It certainly does.
I was actually able to test this today on SQL 2008 R2. Although the first time I have done these steps was on a SQL 2005 server. If you want the short story "Index your View" it will keep you from supplying the cause of some serious performance issues.
I have a reporting project that needs two views of the same table Ordered by differant DATETIME columns in DESCENDING ORDER. Both columns are listed in the Table Indexes with other columns in the middle of the ordering of included columns. The Table Data size is over 500MB with 4+Million rows.
I created the views and used the normal "TOP(100) PERCENT" syntax and "ORDER BY DESC" syntax inserted by the View Designer in SSMS when selecting a sorted column and Descending order. When selecting from the view these statements had no affect. The data came out of the view with the same order as the indexed Table default. Then I updated both Views to use " TOP (999999999) ". Now the data came out of the table, but the performance was terible. It took 3 seconds to get the TOP 10000 rows from the view that was ordered. Then I understood what was really going on with this change. Why ruin the performance of select from a good view with an order by statement when an Index is really needed. So I removed the TOP and ORDER BY statements, Schema bound the table, and created descending indexes on the DateTime columns for each view.
Sucess! Not only was my view ordered in the right way, but to first 10000 rows came back out in less than 10ms.