Je obecně rychlejší vybrat do dočasné tabulky než vybrat do skutečné tabulky?

zápis do tempdb je rychlejší než skutečná tabulka, která není v tempdb

Je to pravda. V TempDb existují dvě vylepšení IO.

Zápisy do tabulky v databázi uživatelů musí mít své záznamy protokolu vyprázdněny na disk při odevzdání, nebo pokud minimálně protokolovaná vložka (jako SELECT … INTO), musí být stránky databáze vyprázdněny na disk při potvrzení. Způsob minimálního protokolování v databázi uživatelů spočívá v tom, že se stránky databáze zapisují přímo na disk. Po dokončení příkazu SELECT … INTO budou všechny nové stránky zapsány do fyzických souborů.

Zápisy TempDb nemusí být při odevzdání vyprázdněny na disk, protože TempDb se po selhání nikdy neobnoví. Takže prostě nejsou t. Vaše změny generují záznamy protokolu, ale vyrovnávací paměť protokolu je vyprázdněna na disk, pouze když je plná, ne pro každý odevzdání.

A od serveru SQL Server 2014 se minimálně protokolované vložky v TempDb vždy nezapisují ani na disk. Pokud načtete malý, krátkodobá dočasná tabulka, na kterou se vůbec nemusí nikdy zapsat. Protokol bude obsahovat několik záznamů o přidělení stránek a položkách metadat pro tabulku, ale to je vše.

EG spustit následující dávku v tempdb, úplnou databázi pro obnovení a jednoduchou databázi pro obnovení, abyste viděli rozdíly.

drop table if exists foo go declare @data bigint declare @log bigint select @log = sum(case when type_desc = "LOG" then num_of_bytes_written end) ,@data = sum(case when type_desc = "ROWS" then num_of_bytes_written end) from sys.database_files f cross apply sys.dm_io_virtual_file_stats(db_id(),f.file_id) fs select * into foo from sys.objects select -@log + sum(case when type_desc = "LOG" then num_of_bytes_written end) log_bytes ,-@data + sum(case when type_desc = "ROWS" then num_of_bytes_written end) data_bytes , (select recovery_model_desc from sys.databases where database_id = db_id()) recovery_model from sys.database_files f cross apply sys.dm_io_virtual_file_stats(db_id(),f.file_id) fs 

a uvidíte něco jako:

Pro jednoduché obnovení:

log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 24576 16384 SIMPLE 

pro úplné zotavení:

log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 36864 0 FULL 

a pro tempdb:

log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 0 0 SIMPLE 

Někdy pro tempdb uvidíte vyprázdnění vyrovnávací paměti protokolu:

log_bytes data_bytes recovery_model -------------------- -------------------- --------------- 61440 0 SIMPLE 

Komentáře

• Existuje případ, kdy je počáteční vložka rychlejší, ale vrátí se, aby vás později kousla. Tato ukázka ukazuje dotaz, který přenáší data do mezipaměti vyrovnávací paměti, což trvá mnohem déle, protože líný zapisovatel je zaneprázdněn zápisem na tempdb stránky disku, které jsou špinavé pro dočasnou tabulku, která již neexistuje youtube .com / watch? v = X60ipwYv1Ms & feature = youtu.be
• Ano. ' Existuje potenciální budoucí vylepšení, které eliminuje vyplavování stránek vyrovnávací paměti, které nejsou přiděleny žádnému objektu. Načtení velké dočasné tabulky však vždy bude řídit vstupně-výstupní operace, a to buď přímo, nebo nepřímo snížením dostupné paměti pro ukládání do mezipaměti.

Stejně jako zápisy do tempdb často ne každý zasažený vstup / výstup na disk / síť, rozšířený v odpovědi Davida Browna , v závislosti na vašem vstupu konfigurace zjistíte, že i když jsou data dostatečně velká, aby je bylo možné zařadit na disk, jsou stále rychlejší než výběr do „normální“ tabulky:

• TempDB může být na různých disky, takže máte vlastní šířku pásma IO. To je důležité zejména u rotujících disků, nikoli SSD. Čtení z a zápisu do stejné databáze (nebo jiné databáze na stejných jednotkách) bude vyžadovat více pohybů hlavy, které přidat více IO latence a potenciálně omezit vaši efektivní šířku pásma IO. Kopírování dat mezi databázemi na různých discích / polích nebude mít stejnou extra latenci.

• TempDB může být dokonce i fa ster média než vaše hlavní úložiště. Možná na místních discích, kde je hlavní úložiště v síti, nebo na NVMe SSD, kde je hlavní úložiště na tradičních discích.

Oba tyto rozdíly lze také vidět uvnitř stejných databáze, pokud používáte více souborových skupin k šíření částí dat mezi různé disky / pole.

Opak může být také pravdou, pokud máte aktivně používáno více databází. Protože TempDB je sdílený prostředek, může být a jednotky / síť, které ho hostují, více zatíženy než datové soubory pro jednotlivé DB.