Általában gyorsabb a temp táblába való kiválasztás, mint a tényleges táblába való kiválasztás?

a tempdb-be történő írás gyorsabb, mint egy tényleges tábla, amely nincs a tempdb-ben

Igaz. A TempDb-ben két IO-bővítés található.

A felhasználói adatbázisban található írások naplóbejegyzéseit a lemezre kell vinni a véglegesítéskor, vagy ha egy minimálisan naplózott beillesztésnél (például a SELECT … INTO) az adatbázis-oldalakat lemezre kell vinni az elkövetésnél. A minimális naplózás a felhasználói adatbázisban úgy működik, hogy az adatbázis-oldalakat közvetlenül a lemezre írják. A SELECT … INTO befejezéséig az új oldalak mind a fizikai fájlokba lettek írva.

A TempDb írásait nem kell lemezt áthelyezni a végrehajtáskor, mivel a TempDb-t soha nem lehet helyreállítani hiba után. Tehát egyszerűen nem “t”. A változtatások naplórekordokat generálnak, de a naplópuffert csak akkor töltik le a lemezre, ha minden megtelt, nem minden elkötelezettség esetén.

És az SQL Server 2014 óta a TempDb minimálisan naplózott betétjeit sem mindig írják lemezre. Ha kicsiet tölt be, rövid életű temp tábla, lehet, hogy soha nem lesz lemezre írva. A naplóban lesz néhány rekord az oldal kiosztásáról és a tábla metaadat-bejegyzéseiről, de ez az.

EG futtassa a következőt kötegelt tempdb-ben, egy teljes helyreállítási adatbázis és egy egyszerű helyreállítási adatbázis a különbségek megtekintéséhez.

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 

és ilyesmit fog látni:

Az egyszerű helyreállítás érdekében:

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

a teljes helyreállításhoz:

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

és tempdb:

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

A tempdb esetében néha a napló puffer kiürül:

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

Megjegyzések

• Van olyan eset, amikor a kezdeti beillesztés gyorsabb, de később visszatér, hogy megharapja. Ez a bemutató egy lekérdezést mutat be, amely adatokat visz be a puffer gyorsítótárába, mivel a lusta író azzal foglalkozik, hogy olyan lemez tempdb oldalakra írjon, amelyek piszkosak egy már nem létező temp tábla számára youtube .com / watch? v = X60ipwYv1Ms & feature = youtu.be
• Igen. ' van egy lehetséges jövőbeni fejlesztés, amely kiküszöböli az egyetlen objektumhoz nem rendelt pufferkészlet-oldalakat. De egy nagy hőmérsékleti tábla betöltése mindig közvetlenül vagy közvetetten meghajtja az IO-t, csökkentve a gyorsítótár számára rendelkezésre álló memóriát.

A tempdb-be történő írások mellett gyakran nem minden ütőlemez / hálózati IO, amire az David Browne válaszában kiterjesztettek, az IO-tól függően A konfiguráció során azt tapasztalhatja, hogy még akkor is, ha az adatok elég nagyok ahhoz, hogy a lemezre spoololjon, még mindig gyorsabb, mint a “normál” táblázatba választani:

• Előfordulhat, hogy a TempDB más és más meghajtók, tehát rendelkezzen saját IO sávszélességgel. Ez különösen a forgó meghajtóknál, nem pedig az SSD-knél jelentõs. Az és írásból ugyanazon adatbázisba (vagy ugyanazon a meghajtón található másik adatbázisba) történő olvasás több fejmozgást igényel, ami adjon hozzá több IO késleltetést, és potenciálisan korlátozza a tényleges IO sávszélességet. Az adatok másolása a különböző meghajtókon / tömbökön lévő adatbázisok között nem lesz azonos extra késleltetéssel.

• Előfordulhat, hogy a TempDB még a fa mint a fő tárhely. Talán azokon a helyi meghajtókon, ahol a fő tárhely a hálózaton van, vagy olyan NVMe SSD-ken, ahol a fő tároló a hagyományos meghajtókon található. adatbázis, ha több fájlcsoportot használ az adatok egy részének elosztására különböző meghajtók / tömbök között.

  Az ellenkezője igaz lehet akkor is, ha több, aktívan használt adatbázis van. Mivel a TempDB megosztott erőforrás, ezért az azt tároló meghajtók / hálózat nagyobb terhelés alatt lehet, mint bármelyik DB adatfájlja.