Comments on: SQL SERVER – Interesting Observation about Order of Resultset without ORDER BY

By: SQL SERVER – Weekly Series – Memory Lane – #004 « SQL Server Journey with SQL Authority

Sat, 24 Nov 2012 01:31:23 +0000

[...] Interesting Observation about Order of Resultset without ORDER BY In industry many developers avoid using ORDER BY clause to display the result in particular order thinking that Index is enforcing the order. In this interesting example, I demonstrate that without using ORDER BY, same table and similar query can return different results. Query optimizer always returns results using any method which is optimized for performance. The learning is There is no order unless ORDER BY is used. [...]

By: Ashwani

Ashwani — Fri, 30 Mar 2012 18:37:33 +0000

Hello Sir:
I have a question.
When Order by is used for a column and there are multiple rows having same value for the column, then what criteria SQL server follows to show the rows.
http://stackoverflow.com/questions/9944894/random-order-of-rows-when-sorting-is-done-on-a-column#comment12698118_9944894

By: Andrew

Andrew — Mon, 01 Dec 2008 17:52:34 +0000

One reason why query optimizer use non-clustered index in this case is probably because the non-clustered index already have the data needed by the query and SQL server doesn’t have to read the data page of the table. That is a big performance gain.

By: SQL SERVER - Interesting Observation - Use of Index and Execution Plan Journey to SQL Authority with Pinal Dave

Sun, 30 Nov 2008 01:30:37 +0000

[...] 30, 2008 by pinaldave Previously I wrote article about SQL SERVER – Interesting Observation about Order of Resultset without ORDER BY and I have received tremendous response from my readers by emails and comments. Readers demanded [...]

By: Travis Alltop

Travis Alltop — Thu, 27 Nov 2008 18:39:28 +0000

“I guess the answer to that is because non-clustered index’s leaf nodes contain the information that allows SQL Server to navigate to the data pages it needs, usually the clustered index keys (ContactID). The non-clustered index contains all the data it needs and no key lookup is required. But if we try something like: SELECT ContactID, _Another_Random_Column_ FROM Person.Contact then we are back of using the cluster index.”

That is correct, that is exactly why it is faster but I’m kind of surprised that people are just now finding this out. Maybe a little refresher in Data Structures 101 is what is needed.

“There is no order unless ORDER BY is used.”

Once again, kind of a no brainer. Sort order is never 100% guaranteed by the query optimzer without the ORDER BY clause, that is why it is included in the SELECT syntax. It is meant to be used.

By: Joe The DBA

Joe The DBA — Tue, 25 Nov 2008 22:12:19 +0000

The execution path is primarily determined by what percent of rows are expected to be returned from the query which is based off of the statistics generated on the table. There are cases where table or index scans are preferable to index seeks. This is why oracle stores the table in a heap style and then you add indexes (though oracle has index organized tables which are identical to sql server clustered indexes).

The reason for this is random reads vs sequential reads. If you are going to access more than about 50% of the rows in a table then you are better off doing a table scan because that is a sequential read. That is likely to be faster than doing random seeks for 50% of the rows into the index. The oracle optimizer is years ahead of where the sql server optimizer is right now.

By: Jerry Hung

Jerry Hung — Tue, 25 Nov 2008 21:27:27 +0000

Very interesting

I observe the same in AdventureWorks2008 on SQL 2008

SELECT TOP 10 * — Clustered index scan
FROM person.Person

BusinessEntityID
1
2
3
4
5

SELECT TOP 10 businessentityid — NonClustered
FROM person.Person

businessentityid
16496
12506
11390
10798
963

By: Ponnu

Ponnu — Tue, 25 Nov 2008 14:12:34 +0000

Nice to know, good one Dave.

By: Ivan Kotev

Ivan Kotev — Tue, 25 Nov 2008 12:54:11 +0000

I guess the answer to that is because non-clustered index’s leaf nodes contain the information that allows SQL Server to navigate to the data pages it needs, usually the clustered index keys (ContactID). The non-clustered index contains all the data it needs and no key lookup is required. But if we try something like: SELECT ContactID, _Another_Random_Column_ FROM Person.Contact then we are back of using the cluster index.

By: Praveen

Praveen — Tue, 25 Nov 2008 07:47:26 +0000

This is great. But one doubt here how non-clustered index wins over clustered? Any idea.