Du måste gå tillbaka och lägga till ORDER BY klausuler till din kod eftersom utan dem är ordern aldrig garanterad. Du hade "tur" tidigare att du alltid fick samma beställning men det var inte för att SQL Server 2008 garanterade det i alla fall. Det hade troligen att göra med dina index eller hur data lagrades på disken.
Om du flyttade till en ny värd när du uppgraderade, kunde bara skillnaden i hårdvarukonfiguration ha ändrat hur dina frågor körs. För att inte nämna det faktum att den nya servern skulle ha räknat om statistiken på tabellerna och SQL Server 2012-frågeoptimeraren gör förmodligen saker lite annorlunda än den i SQL Server 2008.
Det är en felaktighet att du kan lita på ordningen för en resultatuppsättning i SQL utan att uttryckligen ange i vilken ordning du vill ha det. SQL-resultat ALDRIG har en beställning som du kan lita på utan att använda en ORDER BY klausul. SQL är uppbyggt kring mängdlära. Frågeresultat är i princip set (eller multi-set).
Itzik Ben-Gan ger en bra beskrivning av mängdteori i relation till SQL i sin bok Microsoft SQL Server 2012 T-SQL Fundamentals
Mängdlära, som har sitt ursprung hos matematikern Georg Cantor, är en av de matematiska grenar som relationsmodellen bygger på. Cantors definition av en uppsättning följer:
Med en "uppsättning" menar vi vilken samling M som helst till en helhet av bestämda, distinkta objekt m (som kallas "elementen" av M) av vår uppfattning eller av vår tanke. - Joseph W. Dauben och Georg Cantor (PrincetonUniversity Press, 1990)
Efter en grundlig förklaring av termerna i definitionen fortsätter Itzik med att säga:
Vad Cantors definition av en uppsättning utelämnar är förmodligen lika viktigt som vad den innehåller. Lägg märke till att definitionen inte nämner någon ordning bland setelementen. Ordningen i vilken uppsättningselement listas är inte viktig. Den formella notationen för listuppsättningselement använder parenteser:{a, b, c}. Eftersom ordning inte har någon relevans kan du uttrycka samma uppsättning som {b, a, c} eller {b, c, a}. Om man hoppar vidare till denna uppsättning attribut (kallade kolumner i SQL) som utgör rubriken för arelation (kallas en tabell i SQL), antas ett element identifieras med namn - inte ordningsposition. På samma sätt, överväg uppsättningen av tupler (kallade rader av SQL) som utgör kroppen av relationen; ett element identifieras av dess nyckelvärden - inte av position. Många programmerare har svårt att anpassa sig till tanken att det inte finns någon ordning bland raderna med avseende på frågetabeller. Med andra ord kan en fråga mot en tabell returnera rader i valfri ordning såvida du inte uttryckligen begär att uppgifterna sorteras på ett specifikt sätt, kanske i presentationssyfte.
Men oavsett den akademiska definitionen av en uppsättning har till och med implementeringen i SQL-servern aldrig garanterat någon ordning i resultaten. Detta MSDN-blogginlägg från 2005 av en medlem av frågeoptimeringsteamet säger att du inte ska lita på beställningen från mellanliggande operationer alls.
Omordningsreglerna kan och kommer att bryta mot detta antagande (och gör det när det är obekvämt för dig, utvecklaren;)). Vänligen förstå att när vi ordnar om operationer för att hitta en mer effektiv plan, kan vi orsaka att beställningsbeteendet ändras för mellannoder i trädet. Om du har lagt en operation i trädet som antar separat mellanordning kan den gå sönder.
Det här blogginlägget av Conor Cunningham (arkitekt, SQL Server Core Engine) "No Seatbelt - Expecting Order without ORDER BY" handlar om SQL Server 2008. Han har en tabell med 20k rader i den med ett enda index som alltid ser ut att returnera rader i samma ordning. Lägger till en ORDER BY till frågan ändrar inte ens exekveringsplanen, så det är inte som att lägga till en gör frågan dyrare om optimeraren inser att den inte behöver den. Men när han väl lägger till ytterligare 20 000 rader i tabellen ändras plötsligt frågeplanen och nu använder den parallellism och resultaten är inte längre ordnade!
Det svåra här är att det inte finns något rimligt sätt för någon extern användare att veta när en plan kommer att ändras. Utrymmet för alla planer är enormt och gör ont i huvudet att begrunda. SQL Servers optimerare kommer att ändra planer, även för enkla frågor, om tillräckligt många av parametrarna ändras. Du kan ha tur och inte ha en planändring, eller så kan du helt enkelt inte tänka på det här problemet och lägga till en BESTÄLLNING AV.
Om du behöver mer övertygande, läs bara dessa inlägg:
- Utan ORDER BY finns det ingen standardsortering. - Alexander Kuznetsov
- Ordning i domstolen! - Thomas Kyte
- Ordning av en resultatuppsättning i SQL - Timothy Wiseman