Dela via

Indexjustering i Azure Database for PostgreSQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Indexjustering är en funktion i Azure Database for PostgreSQL – flexibel server som automatiskt förbättrar arbetsbelastningens prestanda genom att analysera spårade frågor och tillhandahålla indexrekommendationer.

Det är ett inbyggt erbjudande i Azure Database for PostgreSQL – flexibel server, som bygger på monitorprestanda med funktioner för frågearkiv . Indexjustering analyserar arbetsbelastningen som spåras av frågearkivet och ger indexrekommendationer för att förbättra prestanda för den analyserade arbetsbelastningen eller för att släppa duplicerade eller oanvända index.

Allmän beskrivning av indexjusteringsalgoritmen

index_tuning.mode När serverparametern har konfigurerats för reportstartas justeringssessioner automatiskt med den frekvens som konfigurerats i serverparametern index_tuning.analysis_interval, uttryckt i minuter.

I den första fasen söker justeringssessionen efter listan över databaser där den anser att de rekommendationer som den kan ge kan påverka systemets övergripande prestanda avsevärt. För att göra det samlar den in alla frågor som registrerats av frågearkivet vars körningar registrerades inom uppslagsintervallet som den här justeringssessionen fokuserar på. Uppslagsintervallet sträcker sig för närvarande till de senaste index_tuning.analysis_interval minuterna, från starttiden för justeringssessionen.

För alla användarinitierade frågor med körningar som registrerats i frågearkivet och vars körningsstatistik inte återställs rangordnar systemet dem baserat på deras aggregerade totala körningstid. Den fokuserar sin uppmärksamhet på de mest framträdande frågorna, baserat på deras varaktighet.

Följande frågor undantas från listan:

  • Systeminitierade frågor. (det vill: frågor som körs av azuresu roll)
  • Frågor som körs i kontexten för alla systemdatabaser (azure_sys, , template1template0och azure_maintenance).

Algoritmen itererar över måldatabaserna och söker efter möjliga index som kan förbättra prestandan för analyserade arbetsbelastningar. Den söker också efter index som kan elimineras eftersom de identifieras som dubbletter eller inte används under en konfigurerbar tidsperiod.

SKAPA INDEX-rekommendationer

Alla SELECT-, UPDATE-, INSERT- och DELETE-frågor som körs under uppslagsintervallet och i kontexten för den specifika databasen räknas in för varje databas som identifieras som en kandidat att analysera för att ta fram indexrekommendationer.

Den resulterande uppsättningen frågor rangordnas baserat på deras aggregerade totala körningstid och den översta index_tuning.max_queries_per_database analyseras för möjliga indexrekommendationer.

Potentiella rekommendationer syftar till att förbättra prestandan för dessa typer av frågor:

  • Frågor med filter (d.ex. frågor med predikat i WHERE-satsen),
  • Frågor som ansluter till flera relationer, oavsett om de följer syntaxen där kopplingar uttrycks med JOIN-satsen eller om kopplingspredikaten uttrycks i WHERE-satsen.
  • Frågor som kombinerar filter och kopplingspredikat.
  • Frågor med gruppering (frågor med en GROUP BY-sats).
  • Frågor som kombinerar filter och gruppering.
  • Frågor med sortering (frågor med en ORDER BY-sats).
  • Frågor som kombinerar filter och sortering.

Kommentar

Den enda typen av index som systemet för närvarande rekommenderar är de av typen B-Tree.

Om en fråga refererar till en kolumn i en tabell och tabellen inte har någon statistik hoppar den över hela frågan och ger inga indexrekommendationer för att förbättra körningen.

Analys som krävs för att samla in statistik kan utlösas manuellt med hjälp av kommandot ANALYZE eller automatiskt av daemonen autovacuum.

index_tuning.max_indexes_per_table anger antalet index som kan rekommenderas, exklusive index som kanske redan finns i tabellen för en enskild tabell som refereras till av valfritt antal frågor under en justeringssession.

index_tuning.max_index_count anger antalet indexrekommendationer som skapats för alla tabeller i en databas som analyserats under en justeringssession.

För att en indexrekommendering ska genereras måste justeringsmotorn uppskatta att den förbättrar minst en fråga i den analyserade arbetsbelastningen med en faktor som anges med index_tuning.min_improvement_factor.

På samma sätt kontrolleras alla indexrekommendationer för att säkerställa att de inte introducerar regression på en enskild fråga i den arbetsbelastningen för en faktor som anges med index_tuning.max_regression_factor.

Kommentar

index_tuning.min_improvement_factor och index_tuning.max_regression_factor båda refererar till kostnaden för frågeplaner, inte deras varaktighet eller de resurser som de använder under körningen.

Alla parametrar som nämns i föregående stycken, deras standardvärden och giltiga intervall beskrivs i konfigurationsalternativ.

Skriptet som skapas tillsammans med rekommendationen att skapa ett index följer det här mönstret:

create index concurrently {indexName} on {schema}.{table}({column_name}[, ...])

Den innehåller -satsen concurrently. Mer information om effekterna av den här satsen finns i PostgreSQL officiell dokumentation för CREATE INDEX.

Indexjustering genererar automatiskt namnen på de rekommenderade indexen, som vanligtvis består av namnen på de olika nyckelkolumnerna avgränsade med "_" (understreck) och med ett konstant suffix "_idx". Om namnets totala längd överskrider PostgreSQL-gränserna eller om det krockar med befintliga relationer är namnet något annorlunda. Det kan trunkeras och ett tal kan läggas till i slutet av namnet.

Beräkna effekten av en CREATE INDEX-rekommendation

Effekten av att skapa en indexrekommendation mäts på IndexSize (megabyte) och QueryCostImprovement (procent).

IndexSize är ett enda värde som representerar indexets uppskattade storlek, med tanke på tabellens aktuella kardinalitet och storleken på de kolumner som refereras till av det rekommenderade indexet.

QueryCostImprovement består av en matris med värden, där varje element representerar förbättringen av planens kostnad för varje fråga vars plankostnad beräknas förbättras om indexet finns. Varje element visar frågans identifierare (frågad) och den procentandel med vilken planens kostnad skulle förbättras om rekommendationen implementerades (dimensionell).

DROP INDEX- och REINDEX-rekommendationer

För varje databas som indexjusteringsfunktionen bestäms för bör den initiera en ny session, och när fasen CREATE INDEX-rekommendationer har slutförts rekommenderar den att befintliga index tas bort eller indexeras om baserat på följande kriterier:

  • Släpp om det anses vara en dubblett av andra.
  • Släpp om den inte används under en konfigurerbar tidsperiod.
  • Indexera om index som har markerats som ogiltiga.

Ta bort duplicerade index

Rekommendationer för att ta bort duplicerade index: Identifiera först vilka index som har dubbletter.

Dubbletter rangordnas baserat på olika funktioner som kan hänföras till indexet och baseras på deras uppskattade storlekar.

Slutligen rekommenderar vi att du tappar alla dubbletter med en lägre rangordning än referensledaren och beskriver varför varje dubblett rangordnades som den var.

För att två index ska betraktas som duplicerade måste de:

  • Skapas över samma tabell.
  • Vara ett index av exakt samma typ.
  • Matcha deras nyckelkolumner och matcha i vilken ordning de refereras för indexnycklar med flera kolumner.
  • Matcha uttrycksträdet för dess predikat. Gäller endast för partiella index.
  • Matcha uttrycksträdet för alla icke-exempelkolumnreferenser. Gäller endast för index som skapats för uttryck.
  • Matcha sorteringen för varje kolumn som refereras till i nyckeln.

Ta bort oanvända index

Rekommendationer för att ta bort oanvända index identifierar de index som:

  • Används inte på minst index_tuning.unused_min_period dagar.
  • Visa ett minsta (dagligt genomsnitt) antal index_tuning.unused_dml_per_table DML:er i tabellen där indexet skapas.
  • Visa ett minsta (dagligt genomsnitt) antal index_tuning.unused_reads_per_table läsningar i tabellen där indexet skapas.

Indexera om ogiltiga index

Rekommendationer för omindexering av befintliga index identifierar de index som har markerats som ogiltiga. Mer information om varför och när index markeras som ogiltiga finns i den officiella dokumentationen om REINDEX i PostgreSQL.

Beräkna effekten av en DROP INDEX-rekommendation

Effekten av en rekommendation för släppindex mäts på två dimensioner: Förmån (procent) och IndexSize (megabyte).

Förmånen är ett enda värde som kan ignoreras för tillfället.

IndexSize är ett enda värde som representerar indexets uppskattade storlek, med tanke på tabellens aktuella kardinalitet och storleken på de kolumner som refereras till av det rekommenderade indexet.

Konfigurera indexjustering

Indexjustering kan aktiveras, inaktiveras och konfigureras via en uppsättning parametrar som styr dess beteende, till exempel hur ofta en justeringssession kan köras.

Utforska all information om korrekt konfiguration av indexjusteringsfunktionen i hur du aktiverar, inaktiverar och konfigurerar indexjustering.

Information som produceras av indexjustering

Hur du läser, tolkar och använder rekommendationer som genereras av indexjustering beskriver i detalj hur du hämtar och använder rekommendationerna från indexjustering.

Begränsningar och support

Här följer listan över begränsningar och supportomfång för indexjustering.

Beroende av hypopg-tillägg

För indexjustering för att skapa CREATE INDEX-rekommendationer använder den hypopg-tillägget .

Om tillägget redan finns när en justeringssession börjar används det i schemat där det skapades. Och när justeringssessionen är klar tas inte tillägget bort. Ett undantag till detta är om tillägget skapades i pg_catalog schemat. I så fall släpper indexjustering tillägget.

Om tillägget inte fanns i första hand eller om vi tappade det eftersom det skapades i pg_catalog schemat, skapar indexjustering det under ett schema som heter ms_temp_recommendations709253 och när justeringssessionen har slutförts tas tillägget bort och schemat tas bort.

Användare som är medlemmar azure_pg_admin i rollen kan släppa hypopg-tillägget när som helst, även när det skapades av indexjusteringsfunktionen. Om du släpper den medan en indexjusteringssession körs kan det dock leda till att sessionen misslyckas och inte ger några rekommendationer.

Beräkningsnivåer och SKU:er som stöds

Indexjustering stöds på alla tillgängliga nivåer: Burstable, Generell användning och Minnesoptimerad och på alla beräknings-SKU:er som stöds för närvarande med minst 4 virtuella kärnor.

Versioner av PostgreSQL som stöds

Indexjustering stöds i huvudversionerna 12 eller senare av Azure Database for PostgreSQL – flexibel server.

Användning av search_path

Indexjustering förbrukar värdet som sparats i kolumnen search_path query_store.qs_view, så att när varje fråga analyseras anges samma värde search_path som när frågan som kördes ursprungligen är den som den är inställd på för att analysera möjliga rekommendationer.

Parametriserade frågor

Parametriserade frågor som skapats med PREPARE eller med hjälp av det utökade frågeprotokollet parsas och analyseras för att skapa indexrekommendationer för dem.

För analys av parametriserade frågor kräver indexjustering att pg_qs.parameters_capture_mode anges till capture_first_sample när frågearkivet registrerar körningen av frågan. Det kräver också att parametrarna registreras korrekt av frågearkivet när frågan körs. För den fråga som analyseras måste med andra ord query_store.qs_view ha kolumnen parameters_capture_status inställd på succeeded.

Skrivskyddat läge och skrivskyddade repliker

Eftersom indexjustering är beroende av frågearkiv, som inte stöds i skrivskyddade repliker eller när en instans är i skrivskyddat läge, stöder vi den inte på skrivskyddade repliker eller på instanser som är i skrivskyddat läge.

Alla rekommendationer som visas på en läsreplik producerades på den primära repliken efter att enbart ha analyserat arbetsbelastningen som kördes på den primära repliken.

Nedskalning av beräkning

Om indexjustering är aktiverat på en server och du skalar ned serverns beräkning till mindre än det minsta antalet nödvändiga virtuella kärnor är funktionen fortfarande aktiverad. Eftersom funktionen inte stöds på servrar med mindre än 4 virtuella kärnor körs den inte för att analysera arbetsbelastningen och skapa rekommendationer, även om index_tuning.mode den har angetts till ON när beräkningen skalades ned. Även om servern inte uppfyller minimikraven är alla index_tuning.* serverparametrar otillgängliga. När du skalar servern tillbaka till en beräkning som uppfyller minimikraven index_tuning.mode konfigureras den med det värde som angavs innan du skalade ned den till en beräkning som inte uppfyllde kraven.

Hög tillgänglighet och läsrepliker

Om du har hög tillgänglighet eller läsrepliker som konfigurerats på servern bör du vara medveten om konsekvenserna av att skapa skrivintensiva arbetsbelastningar på den primära servern när du implementerar de rekommenderade indexen. Var särskilt försiktig när du skapar index vars storlek uppskattas vara stor.

Relaterat innehåll