SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Order of rows in a Table with Identity Column.


Order of rows in a Table with Identity Column.

Author
Message
jignesh209
jignesh209
SSC-Enthusiastic
SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)

Group: General Forum Members
Points: 162 Visits: 185
I have a table with an Identity Column as TransactionId and also it is a primary key.
The table has around 9 Million rows.
The table also has number of columns and in that one is OrderNumer.

Now,if I query it by SELECT * FROM OrderTransaction where OrderNumber=89856.It returns 2 rows.

TransactionId OrderNumber
1015 89856
1016 89856

Will the query(this query with no ORDER BY) always return in the order mentioned above or it will return rows in the order as:
TransactionId OrderNumber
1016 89856
1015 89856
Lynn Pettis
Lynn Pettis
SSC Guru
SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)

Group: General Forum Members
Points: 95231 Visits: 38967
jerry209 (7/1/2013)
I have a table with an Identity Column as TransactionId and also it is a primary key.
The table has around 9 Million rows.
The table also has number of columns and in that one is OrderNumer.

Now,if I query it by SELECT * FROM OrderTransaction where OrderNumber=89856.It returns 2 rows.

TransactionId OrderNumber
1015 89856
1016 89856

Will the query(this query with no ORDER BY) always return in the order mentioned above or it will return rows in the order as:
TransactionId OrderNumber
1016 89856
1015 89856




The only way to guarantee order you must use an ORDER BY clause in your query. SQL Server will not guarantee the order of the data otherwise.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Joie Andrew
Joie Andrew
SSCertifiable
SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)

Group: General Forum Members
Points: 6465 Visits: 2032
The only way to guarantee order you must use an ORDER BY clause in your query. SQL Server will not guarantee the order of the data otherwise.


+1

Set theory does not guarantee the order of a result set. The only way to guarantee it is with an order by clause (or have your app sort the results).

Joie Andrew
"Since 1982"
Sean Lange
Sean Lange
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: General Forum Members
Points: 62829 Visits: 17959
Check out this article that explains what is happening and some great example to help you understand ordering.

http://blogs.msdn.com/b/conor_cunningham_msft/archive/2008/08/27/no-seatbelt-expecting-order-without-order-by.aspx

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
dwain.c
dwain.c
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17889 Visits: 6431
Excuse me for asking a dumb question here but the OP says the TransactionID is the primary key with presumably a clustered index on it (my assumption).

In that case, without an ORDER BY shouldn't the rows be returned in the order established by the clustered INDEX?

Otherwise, how would a QU ever work?


My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Joie Andrew
Joie Andrew
SSCertifiable
SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)

Group: General Forum Members
Points: 6465 Visits: 2032
I could be wrong, but I believe a clustered index is for how the data is stored, not retrieved. From what I've read the optimizer can take various ways of retrieving rows depending on what it thinks is fastest. If you have a table with pages split across several disks there could be multiple read operations bringing back different sets of data at different times. Without an order by clause it will return the data in whatever order it gets it in first; all it has to guarantee is the data, not the order of the data.

Joie Andrew
"Since 1982"
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)

Group: General Forum Members
Points: 215851 Visits: 41981
dwain.c (7/8/2013)
Excuse me for asking a dumb question here but the OP says the TransactionID is the primary key with presumably a clustered index on it (my assumption).

In that case, without an ORDER BY shouldn't the rows be returned in the order established by the clustered INDEX?

Otherwise, how would a QU ever work?


That's a part of the bone of contention that some folks have with the Quirky Update. The QU depends on the use of the Clustered Index AND that it's used in an "ORDERED" fashion. That's the reason for all the rules such a MAXDOP 1 and referencing the lead column of the CI, etc. Paul White came up with a method (referenced at the beginning of the "latest" article) that uses a CTE with a RowNumber and a counter in the outer query that must match or it gives you an error. Oddly enough, the method seems to guarantee that if the QU is setup correctly to run to begin with, it'll never error.

As for relying on the CU for a "natural" sort of other things goes, it's not guaranteed especially if there's another unique index on the table. Other than some of the trickery in the rules of a QU, the only way to guarantee order in a SELECT is to use an ORDER BY. If SQL Server decides to use the CI in an "ORDERED" mode, it'll ignore the sort... it won't even include it in the execution plan.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
GilaMonster
GilaMonster
SSC Guru
SSC Guru (225K reputation)SSC Guru (225K reputation)SSC Guru (225K reputation)SSC Guru (225K reputation)SSC Guru (225K reputation)SSC Guru (225K reputation)SSC Guru (225K reputation)SSC Guru (225K reputation)

Group: General Forum Members
Points: 225413 Visits: 46321
dwain.c (7/8/2013)
In that case, without an ORDER BY shouldn't the rows be returned in the order established by the clustered INDEX?


No. Without an order by there is no guarantee of the order that the rows will be returned in. Now, for a simple select * without parallelism, the data will probably come back in the order of the index used for the query, because that's the order the QP left it in after the last query operator. However don't confuse probable behaviour with guaranteed behaviour, without an order by there is no guaranteed order.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


dwain.c
dwain.c
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17889 Visits: 6431
Jeff and Gila,

Thanks for the clarifications. I take it you're saying that even with a MAXDOP 1 on the simple SELECT it doesn't guarantee row ordering.

My question was mostly speculative because I would always write it with an ORDER BY to be certain. I probably should have added a "usually" to my comment.

However I would be interested to see a case where a simple SELECT doesn't return rows ordered by the CI. I am not doubting either of you when I say this, just trying to learn more about it.

I also realize that doing other things in the SELECT (e.g., JOIN to another table) would certainly lower the likelihood of rows returned in the CI order.

Jeff - I am unclear on where to find the article you referenced from Paul White.


My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)SSC Guru (215K reputation)

Group: General Forum Members
Points: 215851 Visits: 41981
It wasn't an article. It was a post on the Running Total article and Tom updated it with a slightly different take on the check. Tom's post with both his an Paul White's code puts it altogether quite nicely at the following post, the URL for which is also posted at the beginning of the Running Total article. Heres' the link for Paul and Tom's contribution.
http://www.sqlservercentral.com/Forums/FindPost981258.aspx

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search