Fortolkning af plannoder
Lær at afkode almindelige plannoder som sekventielle scans, index scans, join-typer og sorteringer.
Fortolkning af plannoder er en gratis Ydelsesoptimering og optimering af forespørgsler i PostgreSQL-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Ydelsesoptimering og optimering af forespørgsler i PostgreSQL, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Ydelsesoptimering og optimering af forespørgsler i PostgreSQL-kurset indeholder 4 lektioner i alt.
Aflæsning af forespørgselsplaner
Velkommen tilbage! I den forrige lektion lærte du at bruge EXPLAIN til at se en forespørgsels udførelsesplan. Nu skal vi se nærmere på fortolkningen af de forskellige »noder« i disse planer.
Hver node repræsenterer en bestemt handling, som PostgreSQL udfører. Det er afgørende at forstå dem for at kunne identificere flaskehalse i ydeevnen.
Hvad er plannoder?
Forestil dig en forespørgselsplan som et træ, hvor hver gren og hvert blad er en »node«. Disse noder fortæller dig:
- Hvilken handling der udføres (f.eks. scanning, sortering eller sammenføjning).
- Hvordan den udføres (f.eks. sekventielt eller ved hjælp af et indeks).
- Omkostningsestimater: Hvor meget tid og hvor mange ressourcer PostgreSQL *forventer*, at handlingen vil kræve.
Vi ser på de mest almindelige og vigtigste nodetyper.
Sekventiel scanning: Den fulde læsning
En sekventiel scanning (ofte kaldet en »Seq Scan«) betyder, at PostgreSQL læser hver eneste række i en tabel fra start til slut for at finde de data, der er brug for.
- Hvornår det sker: For små tabeller, eller når du forespørger på en stor del af en tabel uden et egnet indeks.
- Ydeevnepåvirkning: Det kan være langsomt for store tabeller, især hvis der kun er brug for nogle få rækker.
Det svarer til at kigge alle siderne i en bog igennem for at finde én bestemt sætning.
Eksempel på Seq Scan
Lad os se en sekventiel scanning i praksis. Vi opretter en enkel tabel og forespørger derefter på den uden et indeks.
CREATE TABLE products (
product_id SERIAL PRIMARY KEY,
name VARCHAR(100),
price DECIMAL(10, 2)
);
INSERT INTO products (name, price) VALUES
('Laptop', 1200.00),
('Mouse', 25.00),
('Keyboard', 75.00),
('Monitor', 300.00);
EXPLAIN SELECT * FROM products WHERE price > 100;Indeksscanning: Målrettet søgning
En indeksscanning er langt mere effektiv. PostgreSQL bruger et indeks til hurtigt at finde de bestemte rækker, der er brug for, ligesom når du bruger et indeks i en bog.
- Hvornår det sker: Når en forespørgsel bruger en
WHERE-sætning på en indekseret kolonne, og indekset er tilstrækkeligt selektivt. - Ydeevnepåvirkning: Det er generelt meget hurtigere end en sekventiel scanning for selektive forespørgsler på store tabeller.
Det gør det muligt for PostgreSQL at springe direkte til de relevante datasider.
Eksempel på indeksscanning
Lad os nu tilføje et indeks til vores products-tabel og se ændringen i forespørgselsplanen.
CREATE INDEX idx_products_price ON products (price);
EXPLAIN SELECT * FROM products WHERE price > 100;Sorteringsnode: Sortering af data
Noden Sort vises, når PostgreSQL skal sortere data, typisk på grund af en ORDER BY- eller GROUP BY-sætning, og der ikke findes et indeks, som kan levere dataene i den ønskede rækkefølge.
- Hvornår det sker: Ved en eksplicit
ORDER BYeller implicit ved visse handlinger somGROUP BYeller entydighedsbegrænsninger. - Ydeevnepåvirkning: Sortering kan være krævende for CPU og I/O, især for store datasæt.
Hvis sorteringen foregår »på disken« (det vil sige, hvis den ikke kan være i hukommelsen), bliver den endnu langsommere.
Eksempel på sorteringsnode
Her er et eksempel, hvor PostgreSQL er nødt til at sortere resultaterne, fordi der ikke findes et indeks for den kolonne, der bestemmer rækkefølgen.
EXPLAIN SELECT name, price FROM products ORDER BY name DESC;Sammenføjningsnoder: Kombination af tabeller
Når du sammenføjer to eller flere tabeller, bruger PostgreSQL bestemte sammenføjningsnoder til at kombinere dataene. Der er tre primære typer:
- Nested Loop Join: Er ofte velegnet til små indre tabeller, eller når der findes et indeks.
- Hash Join: Er effektiv til større tabeller, hvor der ikke findes et nyttigt indeks på sammenføjningsnøglen.
- Merge Join: Kræver, at begge input er sorteret efter sammenføjningsnøglen, hvorefter de flettes.
Valget afhænger af tabellernes størrelse, de tilgængelige indekser og datafordelingen.
Eksempel på Nested Loop Join
Lad os oprette endnu en tabel og derefter sammenføje den med products for at se en Nested Loop Join. Det sker ofte, når den ene side af sammenføjningen er lille.
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
product_id INT,
quantity INT
);
INSERT INTO orders (product_id, quantity) VALUES
(1, 1),
(2, 2),
(1, 3);
EXPLAIN SELECT p.name, o.quantity
FROM products p JOIN orders o ON p.product_id = o.product_id
WHERE o.order_id = 2;Identificer scanningstypen
Se på følgende forespørgsel og uddraget af dens udførelsesplan. Hvilken type scanning udføres sandsynligvis på customers-tabellen?
EXPLAIN SELECT * FROM customers WHERE age > 30;
Delvist planoutput (antag, at der ikke er noget indeks på age):
-> Seq Scan on customers (cost=0.00..10.50 rows=3 width=...)Opsummering: Aflæsning af plannoder
Du har taget et stort skridt i forståelsen af PostgreSQLs ydeevne ved at lære at fortolke vigtige plannoder!
- Sekventiel scanning: Fuld læsning af tabellen, som kan være langsom for store tabeller.
- Indeksscanning: Bruger et indeks til målrettet adgang til rækker og er hurtigere ved selektive forespørgsler.
- Sortering: Forekommer, når data skal sorteres, og der ikke findes et egnet indeks.
- Sammenføjningsnoder: (Nested Loop, Hash, Merge) kombinerer data fra flere tabeller og vælges ud fra datamængden og indekserne.
I den næste lektion bruger vi denne viden til at identificere faktiske flaskehalse i ydeevnen!
Lær SQL med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 22
- Lektioner
- 88
Ofte stillede spørgsmål
Er lektionen “Fortolkning af plannoder” gratis?
Ja — alle 3 lektioner i læringssporet Ydelsesoptimering og optimering af forespørgsler i PostgreSQL, inklusive “Fortolkning af plannoder”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Ydelsesoptimering og optimering af forespørgsler i PostgreSQL-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Fortolkning af plannoder”?
Lær at afkode almindelige plannoder som sekventielle scans, index scans, join-typer og sorteringer. Du øver dig i Ydelsesoptimering og optimering af forespørgsler i PostgreSQL med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Ydelsesoptimering og optimering af forespørgsler i PostgreSQL?
Der kræves ingen tidligere erfaring. Ydelsesoptimering og optimering af forespørgsler i PostgreSQL på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Fortolkning af plannoder”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Ydelsesoptimering og optimering af forespørgsler i PostgreSQL-lektion?
Ja. Alle Ydelsesoptimering og optimering af forespørgsler i PostgreSQL-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Introduktion til EXPLAIN og ANALYZE
- Fortolkning af plannoder
- Identifikation af performanceflaskehalse
- Læsning af EXPLAIN-omkostningsestimater og rækkeantal