Dlaczego SSMS wstawia nowe wiersze na górze tabeli, a nie na dole?

Ilekroć ręcznie wstawiam wiersz do tabeli w SQL Server Management Studio 2008 (bazą danych jest SQL Server 2005), mój nowy wiersz pojawia się na górze listy, a nie na dole. Używam kolumn tożsamości, a to skutkuje takimi rzeczami

id  row
42 first row
1 second row
2 third row

Gdy wiersze są pobierane i nie są jawnie uporządkowane. Powoduje to inny wygląd, gdy wiersze są pobierane do aplikacji sieci web i zmienia to, co TOP 1zwraca zapytanie.

Wiem, że potrafię order by, ale dlaczego tak się dzieje? Większość moich danych jest wstawianych za pośrednictwem aplikacji internetowej, wszystkie wstawki z tej aplikacji skutkują kolejnością Pierwsze na Pierwsze Wyjście, np. Najnowsza wstawka znajduje się na dole, więc identyfikatory są w jednym rzędzie. Czy jest jakieś ustawienie w serwerze lub Management Studio, które powoduje to niewłaściwe zamówienie?

sql-server ssms identity

— Ben Brocka
źródło

Jak czasem widziałem, zależy od kolejności PK, w jaki sposób wiersze są wyświetlane, jeśli wybierzesz pojedynczą tabelę. Jeśli dokonasz niektórych połączeń, może się zmienić w zależności od innych tabel PK, FK i indeksów ...

— Guillermo Gutiérrez

Pamiętaj także o skanowaniu karuzelowym .

— Michael Green

Odpowiedzi:

W świecie SQL porządek nie jest nieodłączną właściwością zestawu danych. W ten sposób nie otrzymujesz żadnych gwarancji z RDBMS, że twoje dane wrócą w określonej kolejności - lub nawet w spójnej kolejności - chyba że zapytasz o dane ORDER BYklauzulą.

Od Craiga Freedmana :

Połączenie TOP z ORDER BY dodaje determinizmu do zestawu zwracanych wierszy. Bez ORDER BY zestaw zwracanych wierszy zależy od planu zapytań i może nawet różnić się w zależności od wykonania.

Zawsze używaj, ORDER BYjeśli spodziewasz się dobrze zdefiniowanej i spójnej kolejności w zestawie wyników. Nigdy nie polegaj na tym, jak baza danych może przechowywać wiersze na dysku (np. Poprzez indeks klastrowany), aby zagwarantować pewną kolejność danych w zapytaniach.

— Nick Chammas
źródło

Aby uzupełnić pozostałe odpowiedzi: tabela jest z definicji nieuporządkowanym zestawem wierszy. Jeśli nie określisz ORDER BYklauzuli, SQL Server może zwrócić wiersze w dowolnej kolejności, którą uzna za najbardziej wydajną. Często zdarza się, że pokrywa się to z kolejnością wstawiania, ponieważ większość tabel ma indeks klastrowy dotyczący tożsamości, daty i godziny lub innych monotonicznie rosnących kolumn, ale należy traktować to dokładnie tak: zbieg okoliczności. Może się zmieniać wraz z nowymi danymi, aktualizacją statystyk, flagą śledzenia, zmianami w maxdop, wskazówkami do zapytań, zmianami przyłączenia lub klauzulami zapytania w zapytaniu, zmianami w optymalizatorze z powodu dodatku Service Pack / aktualizacji zbiorczej / poprawki / aktualizacji, przeniesienie bazy danych na inny serwer itp. itp.

Innymi słowy i wiem, że znasz już odpowiedź, ale nie można jej powiedzieć wystarczająco:

Jeśli chcesz polegać na kolejności zapytań, ZAWSZE dodaj ORDER BY .

— Aaron Bertrand
źródło

Nie planowałem w zależności od zamówienia, ale wizualnie jest trochę denerwujące, że moje ostatnio wstawione elementy są nagle na górze.

— Ben Brocka,

Przypuszczam, że to dlatego, że używasz Open Table. W Management Studio 2008 polecenie to zostało podzielone na „Edytuj górne n wiersze” i „Wybierz górne n wierszy” - po wybraniu drugiego z nich możesz dowolnie edytować wynikowe zapytanie, np. Usunąć górę i dodać zamówienie według.

— Aaron Bertrand

To studio zarządzania 2008, serwer to 2005, powinno być jaśniejsze. Nie wiedziałem, że istnieje polecenie „otwartego stołu”, zawsze korzystałem ze selectstatystyk

— Ben Brocka

Ok, no cóż, punkt nadal stoi, rozumiem, że denerwujące jest to, że dane wracają w kolejności, której się nie spodziewasz, ale mam nadzieję, że teraz jest jasne, dlaczego SQL Server tak naprawdę nie dba o to, jakiej kolejności oczekujesz, chyba że powiesz, że ci zależy dodając zamówienie według klauzuli. :-)

— Aaron Bertrand

Jest tak, ponieważ tabela jest tabelą sterty (najprawdopodobniej) i nie jest indeksowana. Ustaw także kolumnę identyfikatora PRIMARY KEYjako IDENTITY. SQL Server fizycznie przechowuje dane na podstawie indeksów - na przykład, jeśli id byłby indeksem klastrowym (takim jak klucz podstawowy), dane byłyby fizycznie przechowywane w kolejności identyfikatorów i byłyby w ten sposób zwracane w zapytaniu nawet bez ORDER BYklauzula. W przeciwnym razie kolejność wierszy nie jest istotna dla bazy danych. W konsekwencji, mając aplikacji zależy od kolejności wierszy w bazie danych (a także w zależności od kolumn znajdujących się w określonej kolejności) nie jest dobra praktyka. Aplikacja musi pracować z dowolnymi kluczami w bazie danych, aby identyfikować wiersze.

— Wil
źródło

Dobrze wiedzieć. Wiedziałem, że to wskazówka, aby zmienić aplikację, aby była używana order by(jest to aplikacja odziedziczona z dużą ilością złych praktyk), ale zastanawiałem się, dlaczego tak się stało.

— Ben Brocka,

Zmienić strukturę tabeli tak, aby SELECT *bez niej ORDER BY mogła wrócić w „właściwej” kolejności (ale nadal nie ma gwarancji)?

— Aaron Bertrand

Na prosty WYBÓR z tabeli wróciłby indeks klastrowany w kolejności indeksu klastrowanego. Nie było tak jasne, jak powinienem być, że była to ilustracja, kiedy dane fizycznie są uporządkowane według konkretnej kolumny, ale zdecydowanie nie jest pewne, że w każdym zapytaniu byłyby zwracane poprawnie. Mea culpa.

— Wil

Tak naprawdę nie ma znaczenia, czym jest indeks klastrowany. Program SQL Server może nadal zwracać kolejność na podstawie innych indeksów opartych na wielu różnych czynnikach. Utworzenie klucza podstawowego w jakiejś kolumnie NIE gwarantuje, że selekcja bez zamówienia przez nie nagle wróci zawsze uporządkowana według tej kolumny. Czy możesz to zaobserwować przez większość czasu? Pewnie. Ale to nie to samo, co gwarancja. Nigdy nie widziałem niedźwiedzia polarnego na mojej ulicy, ale nie ma pola siłowego niedźwiedzia polarnego, które by to uniemożliwiło.

— Aaron Bertrand

W każdym razie miałem na ORDER BYmyśli, że dodanie klauzuli jest o wiele lepszą gwarancją (nie wspominając o dużo mniej destrukcyjnym) niż wprowadzanie zmian w schemacie do tabeli i nadzieja, że porządkowanie będzie zgodne z oczekiwaniami, na zawsze.

— Aaron Bertrand