Dela via

Läsa datasidor i databasmotorn

gäller för:SQL ServerAzure SQL Managed Instance

I/O från en instans av SQL Server Database Engine innehåller logiska och fysiska läsningar. En logisk läsning sker varje gång databasmotorn begär en sida från buffertcachen, även kallad buffertpoolen. Om sidan för närvarande inte finns i buffertcachen kopierar en fysisk läsning först sidan från disken till cacheminnet.

De läsbegäranden som genereras av en instans av databasmotorn styrs av relationsmotorn och optimeras av lagringsmotorn. Relationsmotorn avgör den mest effektiva åtkomstmetoden (till exempel en tabellgenomsökning, en indexgenomsökning eller en nyckelläsning). Åtkomstmetoderna och bufferthanterarens komponenter i lagringsmotorn avgör det allmänna mönstret för läsningar som ska utföras och optimerar de läsningar som krävs för att implementera åtkomstmetoden. Tråden som kör batchen schemalägger läsningarna.

Läsningsförberedelse

Databasmotorn stöder en mekanism för prestandaoptimering som kallas read-ahead. Read-ahead förutser de data- och indexsidor som behövs för att utföra en frågekörningsplan och laddar sidorna till buffertcachen innan de används av frågan. Den här processen gör att beräkningen och I/O kan överlappa varandra och dra full nytta av både processorn och disken.

Med mekanismen read-ahead kan databasmotorn läsa upp till 64 sammanhängande sidor (512 KB) från en fil. Läsningen utförs som en enskild punktinsamlad läsning till lämpligt antal (förmodligen icke-sammanhängande) buffertar i buffertcachen. Om någon av sidorna i intervallet redan finns i buffertcachen ignoreras motsvarande sida från läsningen när läsningen är klar. Sidintervallet kan också "trimmas" från båda sidor om motsvarande sidor redan finns i cacheminnet.

Det finns två typer av läsning framåt: en för datasidor och en för indexsidor.

Läsa datasidor

Tabellgenomsökningar som används av databasmotorn för att läsa datasidor är effektiva. På sidorna för indexallokeringskarta (IAM) i en SQL Server-databas visas de omfattningar som används av en tabell eller ett index. Lagringsmotorn kan läsa IAM för att skapa en sorterad lista över de diskadresser som måste läsas. Detta gör att lagringsmotorn kan optimera sin I/Os som stora sekventiella läsningar som utförs i följd, baserat på deras plats på disken. Mer information om IAM-sidor finns i Hantera utrymme som används av objekt.

Läsa indexsidor

Lagringsmotorn läser indexsidorna seriellt i nyckelordning. Den här bilden visar till exempel en förenklad representation av en uppsättning lövsidor som innehåller en uppsättning nycklar och den mellanliggande indexnoden som mappar lövsidorna. Mer information om strukturen för sidor i ett index finns i Grupperade och icke-grupperade index.

Diagram över att läsa sidor från buffertcachen.

Lagringsmotorn använder informationen på den mellanliggande indexsidan ovanför lövnivån för att schemalägga seriell läsning för de sidor som innehåller nycklarna. Om en begäran görs för alla nycklar från ABC till DEFläser lagringsmotorn först indexsidan ovanför lövsidan. Den läser dock inte bara varje datasida i följd från sida 504 till sida 556 (den sista sidan med nycklar i det angivna intervallet). I stället söker lagringsmotorn igenom den mellanliggande indexsidan och skapar en lista över lövsidorna som måste läsas. Lagringsmotorn schemalägger sedan alla läsningar i nyckelordning. Lagringsmotorn känner också igen att sidorna 504/505 och 527/528 är sammanhängande och utför en enda punktläsning för att hämta de intilliggande sidorna i en enda åtgärd. När det finns många sidor som ska hämtas i en seriell åtgärd schemalägger lagringsmotorn ett läsblock i taget. När en delmängd av dessa läsningar har slutförts schemalägger lagringsmotorn lika många nya läsningar tills alla nödvändiga läsningar har schemalagts.

Lagringsmotorn använder prefetching för att påskynda uppslag i bastabeller från icke-grupperade index. Lövraderna i ett icke-grupperat index innehåller pekare till de datarader som innehåller varje specifikt nyckelvärde. När lagringsmotorn läser igenom lövsidorna i det icke-klustrade indexet börjar den också schemalägga asynkrona läsningar för de datarader vars pekare redan har hämtats. Detta gör att lagringsmotorn kan hämta datarader från den underliggande tabellen innan den slutför genomsökningen av det icke-illustrerade indexet. Prefetching används oavsett om tabellen har ett grupperat index. SQL Server Enterprise-utgåvan använder mer prefetching än andra utgåvor av SQL Server, vilket gör att fler sidor kan läsas framåt. Nivån för förinläsning kan inte konfigureras i någon utgåva. Mer information om icke-grupperade index finns i Grupperade och icke-grupperade index.

Avancerad genomsökning

I Enterprise-utgåvan av SQL Server tillåter funktionen för avancerad genomsökning flera uppgifter att dela fullständiga tabellgenomsökningar. Om körningsplanen för en Transact-SQL-instruktion kräver en genomsökning av datasidorna i en tabell och databasmotorn upptäcker att tabellen redan genomsöks efter en annan körningsplan, ansluter databasmotorn den andra genomsökningen till den första, på den aktuella platsen för den andra genomsökningen. Databasmotorn läser varje sida en gång och skickar raderna från varje sida till båda exekveringsplanerna. Detta fortsätter tills slutet av tabellen har nåtts.

Då har den första exekveringsplanen de fullständiga resultaten av en genomsökning. Den andra körningsplanen måste dock fortfarande hämta de datasidor som lästes, innan den tog del i den pågående genomsökningen. Genomsökningen efter den andra körningsplanen återvänder sedan till den första datasidan i tabellen och scannar framåt till den punkt där den anslöt till den första genomsökningen. Ett valfritt antal genomsökningar kan kombineras på detta sätt. Databasmotorn fortsätter att loopa igenom datasidorna tills den har slutfört alla genomsökningar. Den här mekanismen kallas även för "merry-go-round scanning" och visar varför ordningen på resultaten som returneras från en SELECT instruktion inte kan garanteras utan en ORDER BY sats.

Anta till exempel att du har en tabell med 500 000 sidor. UserA kör en Transact-SQL-instruktion som kräver en genomsökning av tabellen. När genomsökningen har bearbetat 100 000 sidor UserB kör en annan Transact-SQL-instruktion som söker igenom samma tabell. Databasmotorn schemalägger en uppsättning läsbegäranden för sidor efter 100 001 och skickar raderna från varje sida tillbaka till båda genomsökningarna. När genomsökningen når sidan 200 000 UserC kör du en annan Transact-SQL-instruktion som söker igenom samma tabell. Från och med sidan 200 001 skickar databasmotorn raderna från varje sida som den läser tillbaka till alla tre genomsökningarna. När den har läst den 500 000:e raden är genomsökningen för UserA klar, och genomsökningarna för UserB och UserC går tillbaka och börjar läsa sidorna med början från sida 1. När databasmotorn kommer till sidan 100 000, slutförs genomsökningen för UserB. Sökningen efter UserC fortsätter sedan ensam tills den läser sidan 200 000. Nu har alla genomsökningar slutförts.

Utan avancerad genomsökning skulle varje användare behöva konkurrera om buffertutrymme och orsaka diskarmens konkurrens. Samma sidor skulle sedan läsas en gång för varje användare, i stället för att läsa en gång och delas av flera användare, vilket minskar prestanda och beskattar resurser.

Relaterat innehåll

  • Last updated on