Czy mogę bezpiecznie założyć, że tam, gdzie zapisałem procedury przy użyciu tempdb, aby napisać tabelę tymczasową, lepiej byłoby zmienić te zmienne na tabele, aby uzyskać lepszą wydajność?Używa zmiennych tabeli szybszych niż tabele temp.
Tabele temperatur mają wyższą wydajność. Jeśli używasz zmiennej tabeli, a dane w zmiennej są zbyt duże, SQL Server automatycznie konwertuje zmienną na tabelę tymczasową.
Zależy, jak prawie każde pytanie dotyczące bazy danych, od tego, co próbujesz zrobić. Trudno odpowiedzieć bez większej ilości informacji.
Więc moja odpowiedź brzmi, spróbuj i spójrz na plan wykonania. Użyj najszybszego sposobu przy najniższych kosztach.
Czy mój komentarz na górze ma sens i czy powinienem go zmienić? –
Trudno powiedzieć, zmienić czy nie. Jeśli chcesz zwrócić zmienną tabeli, a twoje operacje są szybkie w obie strony, tak, chciałbym zmienić. Naprawdę powinieneś tego spróbować. Na przykład w zeszłym tygodniu zoptymalizowałem zapytanie, które staje się tak wolne. 20 godzin wcześniej, teraz 2 minuty. Zmieniłem tylko ze zmiennej tabeli na tabelę tymczasową. Zwrócone dane nie były duże, tylko 2000 wierszy, ale wiele operacji i filtrów. – dknaack
"Jeśli użyjesz zmiennej tabeli, a dane w zmiennej staną się zbyt duże, SQL Server automatycznie przekształci zmienną w tabelę tymczasową." To stwierdzenie jest całkowicie fałszywe. –
@Table może być szybciej, jest mniej „czas konfiguracji”, ponieważ obiekt jest tylko w pamięci.
@Tabletki mają jednak wiele chwytów.
Możesz mieć klucz podstawowy na @Tabela, ale to wszystko. Inne indeksy Klastry Nieklastrowane dla kombinacji kolumn nie są możliwe.
Również jeśli twoja tabela ma zawierać rzeczywiste woluminy danych (więcej niż około 200 może 1000 wierszy), wtedy dostęp do tabeli będzie wolniejszy. Zwłaszcza, gdy prawdopodobnie nie będziesz miał przydatnego indeksu.
# Tabele są uciążliwe w procach, ponieważ muszą zostać usunięte podczas debugowania. Tworzenie ich trwa dłużej. i trwają dłużej, ponieważ musisz dodać indeksy jako drugi krok. Ale jeśli masz dużo danych, to ich #tabele za każdym razem.
Nawet w przypadku, gdy w tabeli znajduje się mniej niż 100 wierszy danych, możesz nadal używać # Tabeli, ponieważ możesz utworzyć przydatny indeks na stole.
Podsumowując, używam @Tables przez większość czasu, aby ułatwić wykonywanie prostego procesu itp. Jednak wszystko, co trzeba wykonać, powinno być #Tabela.
Kiedyś wierzyłem w tę bajkę, aż do niedawna utknąłem przy czyszczeniu kwerendy i (jedna z ostatnich rzeczy, które zrobiłem) dokładnie to samo zapytanie (testowałem kilka razy, używając tych samych parametrów) w ciągu 5 sekund, używając '# TempTable' vs 16 sekund za pomocą '@ TableVar' – Jason
@ Tabele nie mają statystyk, więc plan wykonania pociąga za sobą więcej zgadywania. Stąd zalecany górny limit 1000 wierszy. # Tabele mają statystyki, ale te can be cached między wywołaniami. Jeśli twoje umiejętności różnią się znacząco za każdym razem, gdy uruchamia się SP, za każdym razem będziesz chciał REBUILD i RECOMPILE. Oczywiście, jest to koszty ogólne, ale trzeba je zrównoważyć kosztem planu na śmieci.
Oba typy będą wykonywać IO to TempDB.
Nie, @ Tabele nie są panaceum.
Ile rekordów będzie w tabelach tymczasowych, jaka jest konfiguracja serwera, tak jak zmienne tabel mogą być przekazywane do tempdb. http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local-temporary-table.aspx – Kane
Dane są różne, ale to jest dobra uwaga . Jeśli zmienna tabeli będzie bardziej wydajna z niewielką ilością danych, to ją przełączy. –
możliwy duplikat [Czym różni się tabela temp od tabeli w SQL Server?] (Http://stackoverflow.com/questions/27894/whats-the-difference-between-a-temp-table-and-table -variable-in-sql-server) lub to: http: // stackoverflow.com/questions/6991511/sql-server-temp-table-vs-table-variable i prawdopodobnie więcej – gbn