Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric
När du skapar eller återskapar ett index kan du genom att ange alternativet SORT_IN_TEMPDB till PÅ dirigera SQL Server Database Engine att använda tempdb för att lagra mellanliggande sorteringsresultat som används för att skapa indexet. Även om det här alternativet ökar mängden tillfälligt diskutrymme som används för att skapa ett index kan alternativet minska den tid som krävs för att skapa eller återskapa ett index när tempdb finns på en uppsättning diskar som skiljer sig från användardatabasens. Mer information om tempdb finns i Konfigurera konfigurationsalternativet för att skapa minnesserver för index.
Faser i indexskapandet
När databasmotorn skapar ett index går den igenom följande faser:
Databasmotorn söker först igenom datasidorna i bastabellen för att hämta nyckelvärden och skapar en indexbladsrad för varje datarad. När de interna sorteringsbuffertarna har fyllts med bladindexposter sorteras posterna och skrivs till disken som en mellanliggande sorteringsomgång. Databasmotorn återupptar sedan genomsökningen av datasidan tills sorteringsbuffertarna fylls i igen. Det här mönstret för genomsökning av flera datasidor följt av sortering och skrivning av en sorteringskörning fortsätter tills alla rader i bastabellen har bearbetats.
I ett grupperat index är lövraderna i indexet dataraderna i tabellen. Därför innehåller de mellanliggande sorteringskörningarna alla datarader. I ett icke-grupperat index kan lövraderna innehålla icke-nyckelkolumner, men är vanligtvis mindre än ett grupperat index. Om indexnycklarna är stora, eller om det finns flera icke-nyckelkolumner i indexet, kan en icke-klustrad sorteringsoperation vara omfattande. Mer information om hur du inkluderar icke-nyckelkolumner finns i Skapa index med inkluderade kolumner.
Databasens motor sammanfogar de sorterade sekvenserna av rader i indexbladen till en enda, sorterad ström. Komponenten för sorteringssammanslagning i databasmotorn börjar med den första sidan i varje sorteringskörning, hittar den lägsta nyckeln på alla sidor och skickar den lövraden till indexskapandekomponenten. Nästa lägsta nyckel bearbetas och sedan nästa och så vidare. När den sista lövindexraden extraheras från en sorteringskörningssida flyttas processen till nästa sida från den sorteringskörningen. När alla sidor i en sorteringskörnings omfattning har bearbetats frigörs omfattningen. När varje lövindexrad skickas till komponenten för indexskapande inkluderas den på en lövindexsida i bufferten. Varje lövsida skrivs när den fylls. När lövsidor skrivs skapar databasmotorn också indexets övre nivåer. Varje indexsida på den övre nivån skrivs när den fylls.
SORT_IN_TEMPDB-alternativ
När SORT_IN_TEMPDB är inställt på AV, som standard, lagras sorteringskörningarna i målfilgruppen. Under den första fasen av att skapa indexet flyttar de alternerande läsningarna av bastabellsidorna och skrivningar av sorteringen diskens läs-/skrivhuvuden från ett område på disken till ett annat. Huvudena befinner sig i området för datasidan när datasidorna genomsöks. De flyttas till ett område med ledigt utrymme när sorteringsbuffertarna fylls och den aktuella sorteringskörningen måste skrivas till disken och sedan flyttas tillbaka till datasidans område när tabellsidans genomsökning återupptas. Läs-/skrivhuvudets rörelse är större i den andra fasen. Då växlar sorteringsprocessen vanligtvis läsningar från varje sorteringsområde. Både sorteringskörningarna och de nya indexsidorna är inbyggda i målfilgruppen. Det innebär att samtidigt som databasmotorn fördelar läsningar över sorteringspassen måste den periodiskt växla till indexutvidgningarna för att skriva nya indexsidor när de fylls.
Om alternativet SORT_IN_TEMPDB är inställt på PÅ och tempdb finns på en separat uppsättning diskar från målfilgruppen sker läsningarna av datasidorna på en annan disk än skrivningarna till sorteringsarbetsytan i tempdb under den första fasen. Det innebär att diskläsningarna av datanycklarna i allmänhet fortsätter mer seriellt över disken, och skrivningarna till tempdb-disken är också vanligtvis seriella, liksom skrivningarna för att skapa det slutliga indexet. Även om andra användare använder databasen och har åtkomst till separata diskadresser är det övergripande mönstret för läsningar och skrivningar effektivare när SORT_IN_TEMPDB anges än när det inte är det.
Alternativet SORT_IN_TEMPDB kan förbättra kontiguiteten för indexet, särskilt om åtgärden CREATE INDEX inte bearbetas parallellt. Sorteringsarbetsytans storlekar frigörs ganska slumpmässigt med avseende på deras position i databasen. Om sorteringsarbetsytorna finns i destinationens filgrupp, när sorteringsarbetsytorna frigörs kan de tas upp av förfrågningar om utrymmen för att hålla indexstrukturen medan den byggs. Detta kan slumpmässigt förändra positionerna för indexutsträckningarna till en viss grad. Om sorteringsstorlekarna hålls separat i tempdb har sekvensen där de frigörs ingen effekt på indexens plats. När mellanliggande sorteringskörningar lagras i tempdb i stället för målfilgruppen finns det också mer utrymme i målfilgruppen. Detta ökar risken för att indexet blir sammanhängande.
Alternativet SORT_IN_TEMPDB påverkar endast den aktuella satsen. Det finns inga metadataposter som anger om indexet sorterades eller inte sorterades i tempdb. Om du till exempel skapar ett icke-grupperat index med hjälp av alternativet SORT_IN_TEMPDB och vid ett senare tillfälle skapar ett grupperat index utan att ange alternativet, använder databasmotorn inte alternativet när det återskapar det icke-grupperade indexet.
Note
Om en sorteringsåtgärd inte krävs eller om sorteringen kan utföras i minnet ignoreras alternativet SORT_IN_TEMPDB.
Krav på diskutrymme
När du ställer in alternativet SORT_IN_TEMPDB på PÅ måste du ha tillräckligt med ledigt diskutrymme i tempdb för att lagra mellanliggande sorteringskörningar och tillräckligt med ledigt diskutrymme i målfilgruppen för att lagra det nya indexet. CREATE INDEX-instruktionen misslyckas om det inte finns tillräckligt med ledigt utrymme och det finns någon anledning till att databaserna inte kan växa automatiskt för att hämta mer utrymme, till exempel att inget utrymme på disken eller autogrow är inställt på av.
Om SORT_IN_TEMPDB är inställt på AV måste det tillgängliga lediga diskutrymmet i målfilgruppen vara ungefär lika stort som det slutliga indexet. Under den första fasen skapas sorteringsprocesserna och kräver ungefär samma mängd utrymme som det slutliga indexet. Under den andra fasen frigörs varje sorteringskörnings-omfattning när den har bearbetats. Det innebär att sorteringskörningens omfattningar frigörs i ungefär samma takt som de slutliga indexsidorna förvärvas. Därför överskrider de övergripande utrymmeskraven inte större än storleken på det slutliga indexet. En bieffekt av detta är att om mängden ledigt utrymme ligger mycket nära storleken på det slutliga indexet återanvänder databasmotorn vanligtvis sorteringskörningens omfattningar mycket snabbt efter att de har frigjorts. Eftersom sortkörningens omfattningar frigörs på ett något slumpmässigt sätt minskar detta kontinuiteten för indexens omfattningar i det här scenariot. Om SORT_IN_TEMPDB är inställt på OFF förbättras kontinuiteten för indexutbredningen om det finns tillräckligt med ledigt utrymme i målfilgruppen för att indexens omfattningar kan allokeras från en sammanhängande pool i stället för från de nyligen frigjorda sortkörningsutrymmena.
När du skapar ett icke-grupperat index måste du ha tillgängligt som ledigt utrymme:
Om SORT_IN_TEMPDB är inställt på PÅ måste det finnas tillräckligt med ledigt utrymme i tempdb för att lagra sorteringskörningarna och tillräckligt med ledigt utrymme i målfilgruppen för att lagra den slutliga indexstrukturen. Sorteringskörningarna innehåller lövraderna i indexet.
Om SORT_IN_TEMPDB är inställt på AV måste det lediga utrymmet i målfilgruppen vara tillräckligt stort för att lagra den slutliga indexstrukturen. Kontinuiteten för indexet kan förbättras om det finns mer ledigt utrymme.
När du skapar ett klustrat index i en tabell som inte har icke-grupperade index måste du ha tillgängligt som ledigt utrymme:
Om SORT_IN_TEMPDB är inställt på PÅ måste det finnas tillräckligt med ledigt utrymme i tempdb för att lagra sorteringskörningarna. Dessa inkluderar dataraderna i tabellen. Det måste finnas tillräckligt med ledigt utrymme i målfilgruppen för att lagra den slutliga indexstrukturen. Detta inkluderar dataraderna i tabellen och index-B-trädet. Du kan behöva justera uppskattningen för faktorer som att ha en stor nyckelstorlek eller en fyllningsfaktor med ett lågt värde.
Om SORT_IN_TEMPDB är inställt på AV måste det lediga utrymmet i målfilgruppen vara tillräckligt stort för att lagra den slutliga tabellen. Detta inkluderar indexstrukturen. Kontinuiteten i tabellens och indexets omfattningar kan förbättras om det finns mer ledigt utrymme.
När du skapar ett klustrat index i en tabell som har icke-grupperade index måste du ha tillgängligt som ledigt utrymme:
Om SORT_IN_TEMPDB är inställt på PÅ måste det finnas tillräckligt med ledigt utrymme i tempdb för att lagra sorteringssamlingen för det största indexet, vanligtvis det klustrade indexet, och tillräckligt med ledigt utrymme i målfilgruppen för att lagra de slutliga strukturerna för alla index. Detta inkluderar det klustrade indexet som innehåller dataraderna i tabellen.
Om SORT_IN_TEMPDB är inställt på AV måste det lediga utrymmet i målfilgruppen vara tillräckligt stort för att lagra den slutliga tabellen. Detta inkluderar strukturerna för alla index. Kontinuiteten i tabellens och indexets omfattningar kan förbättras om det finns mer ledigt utrymme.
Relaterade uppgifter
Omorganisera och återskapa index
Relaterat innehåll
Konfigurera serverkonfigurationsalternativet för index skapa minne