|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 8:27 PM
Points: 6,735,
Visits: 11,788
|
|
GilaMonster (3/1/2013) Or a TOP 1 (without specifying WITH TIES) where the column you're ordering by has duplicate values Nice. That is a tricky example that might slip by even a good static code analysis rule because it depends on the uniqueness of the column.
__________________________________________________________________________________________________ There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Believe you can and you're halfway there. --Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 4:13 PM
Points: 1,172,
Visits: 2,687
|
|
I think i found the root cause here. The query which we were using brings top 15 records in asc order based on a column which has NULL or 0 0r 1. This was also one of the main columns in the index which did allow nulls, however if i change the index and not include this column then we the null column data would not be in the top 15.
Bottom line is that it was data issue, however i would still like to know from other folks that should i include my column which allows NULL values in my index or it just depends on business reason?
Thanks for your help.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 4:11 PM
Points: 37,741,
Visits: 30,020
|
|
sqldba_newbie (3/4/2013)
I think i found the root cause here. The query which we were using brings top 15 records in asc order based on a column which has NULL or 0 0r 1.
Right, so ordering by a non-unique column and limiting the results. That's the case I showed to opc. Because that column's not unique, when you order by just that you have no guarantee of what order the rows will be within the 'null, 0 or 1' groupings, hence the index changes the assumed order (because it was never guaranteed) and appears to change the results.
The solution here would be to order by a second column that does define the 'correct' order of rows as you want to see them. Removing the column from the index is hiding the symptom, nothing more. There are lots of other things that can and will cause the order of rows to differ from what you assume they should be.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP 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
|
|
|
|