Jaka jest szybkość porównawcza tabel tymczasowych do fizycznych tabel w SQL?

Question

Mam skrypt, który musi tymczasowo wyodrębnić dane, aby wykonywać na nim dodatkowe operacje, ale potem nie trzeba ich przechowywać dalej po uruchomieniu skryptu. Obecnie mam dane w serii tymczasowych tabel lokalnych (CREATE TABLE #table), które są następnie upuszczane po zakończeniu ich użytkowania. Zastanawiałem się, czy przejść na tabele fizyczne, traktowane w ten sam sposób (tabela CREATE TABLE), czy poprawiłaby się prędkość skryptu (lub innych zalet?).

... Czy istnieje różnica w wydajności między tabelami tymczasowymi a tabelami fizycznymi? Z tego, co czytam, tabele tymczasowe są po prostu tabelami fizycznymi, na które może patrzeć tylko sesja uruchomiona przez skrypt (zmniejszanie problemów z blokowaniem).

EDYCJA: Należy zwrócić uwagę, że mówię o tabelach fizycznych a tabelach tymczasowych. Dostępnych jest wiele informacji na temat tabel tymczasowych a zmiennych tabel, np. http://sqlnerd.blogspot.com/2005/09/temp-tables-vs-table-variables.html.

Answer 1

Tabele tymczasowe to duże NIE w programie SQL Server.

• Prowokują ponownej kompilacji planu zapytania, co jest kosztowne.
• Tworzenie i usuwanie tabeli są również kosztownymi operacjami, które dodajesz do procesu.
• Jeśli istnieje duża ilość danych przechodzących do danych tymczasowych, operacje będą powolne z powodu braku indeksów. Możesz tworzyć indeksy na tabelach tymczasowych. Ale nigdy nie polecę tymczasowego stołu dla niczego z dużą ilością rekordów.

Twoje inne podejście: tworzenie i upuszczanie zwykłych tabel powoduje tylko taki sam narzut.

Inne podejście: Można użyć istniejących tabel, rozszerzając wiersze o dodatkową kolumnę w celu rozróżnienia, które rzędy odnoszą się do każdego użytkownika/sesji. Usuwa obciążenie związane z tworzeniem/upuszczaniem tabel, ale musisz być paranoikiem z kodem, który generuje wartość w celu rozróżnienia rzędów ORAZ będziesz musiał opracować sposób na utrzymanie tabeli dla przypadków, w których sesja zakończyła się przedwcześnie i są resztki (wiersze, które nie zostały usunięte na końcu przetwarzania).

Polecam, aby przemyśleć swoją strategię przetwarzania. Niektóre alternatywy są tak proste, jak użycie skorelowanych zapytań, wyprowadzonych tabel lub zmiennych tabelarycznych. Spójrz na: http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx

---

Edit: Podejście tworzenia i upuszczanie regularne stoły i podejście ponowne regularny stolik augumented z dodatkowym polu: Zarówno wygeneruje rekompilacjami planu kwerend, ponieważ ilość danych zmieniona spowoduje ponowne przeprowadzenie ponownej oceny statystyk tabel. Ponownie najlepszym sposobem jest znalezienie alternatywnych sposobów przetwarzania danych.

Answer 2

Przynajmniej dla MySql, jedyną oszczędność czasu, jaką otrzymasz, to oszczędność czasu w tworzeniu tabeli tymczasowej. AFAIK wszystkie tabele są traktowane tak samo na dysku, po prostu kończą się na końcu sesji. To też widziałem w praktyce. Ponownie, to jest mysql 4.x i 5.x

Answer 3

Nie jestem w 100% pewny, ale uważam, że zmienne tabel są ściśle w pamięci, ale tabele tymczasowe znajdują się w tempdb, który jest przechowywany na dysku. To jest za pomocą SQL Server, nie jestem pewien, jak spójne są różne RDMS na ten temat.

Answer 4

Jakiego rodzaju operacje na danych robisz i z jak dużą ilością danych pracujesz?

Będę trzymać się tabel tymczasowych - w przypadku dużych zestawów danych zawsze uważałem, że jest to zdecydowanie najlepszy sposób na zrobienie, a nie tylko na serwerze SQL. Możesz wypróbować globalną tabelę tymczasową (CREATE TABLE ## tablename), która nie ogranicza się tylko do zakresu instrukcji create.

z SQL Server Books Online (2005):

Jeśli utworzyć globalne tymczasowe tabeli ## pracowników, każdy użytkownik w bazie mogą pracować z tej tabeli. Jeśli żaden inny użytkownik nie będzie pracował z tą tabelą po jej utworzeniu, tabela zostanie usunięta po rozłączeniu. Jeśli po utworzeniu przez użytkownika inny użytkownik pracuje z tabelą , SQL Server usuwa ją po rozłączeniu i po tym, jak wszystkie inne sesje nie będą już jej aktywnie używać.

Answer 5

Jedną z rzeczy, którą należy wziąć pod uwagę, jest to, czy można liczyć tylko na jednego użytkownika, który uruchamia ten proces na raz. Jeśli masz równoczesnych użytkowników, opcja zwykłego stołu może powodować zakłócenia. Tabela temp może być unikalna dla użytkownika.