PricingLoginStart free
Prestandaoptimering och frågeoptimering i PostgreSQL · Lektion

Strategier för låsning på radnivå

Utforska avancerade strategier för att hantera lås på radnivå och optimera samtidiga skrivningar.

Lektion 3 av 412 steg

Strategier för låsning på radnivå är en gratis lektion i Prestandaoptimering och frågeoptimering i PostgreSQL på CoddyKit. Detta är lektion 3 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Prestandaoptimering och frågeoptimering i PostgreSQL, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Prestandaoptimering och frågeoptimering i PostgreSQL innehåller totalt 4 lektioner.

Varför låsning på radnivå?

När flera användare eller processer försöker ändra samma data samtidigt behöver databaser ett sätt att förhindra konflikter och säkerställa dataintegriteten. Det är här låsning på radnivå kommer in.

Ett lås på radnivå gör det möjligt för en transaktion att ta exklusiv eller delad åtkomst till specifika rader och hindrar andra transaktioner från att göra motstridiga ändringar tills låset släpps. Detta är avgörande för applikationer med hög samtidighet.

Implicita radlås

PostgreSQL tillämpar automatiskt lås på radnivå under Data Manipulation Language-operationer (DML), till exempel INSERT, UPDATE och DELETE.

  • INSERT: Placerar ett exklusivt lås på den nyligen infogade raden.
  • UPDATE: Placerar ett exklusivt lås på raden som ändras.
  • DELETE: Placerar ett exklusivt lås på raden som tas bort.

Dessa implicita lås säkerställer att endast en transaktion åt gången kan ändra en specifik rad.

Explicita lås: FOR UPDATE

Ibland behöver ni låsa rader innan ni ändrar dem, särskilt när applikationslogiken innebär att data läses, beslut fattas och data sedan uppdateras. Då är SELECT ... FOR UPDATE mycket användbart.

Det hämtar ett exklusivt lås på de valda raderna och hindrar andra transaktioner från att uppdatera eller ta bort dem tills er transaktion genomförs eller återställs.

FOR UPDATE i praktiken

Prova det här exemplet. Om ni kör SELECT ... FOR UPDATE i en databassession och sedan försöker köra UPDATE på samma rad från en annan session kommer den andra sessionen att vänta.

Session 1:

BEGIN;
SELECT * FROM products WHERE product_id = 1 FOR UPDATE;
-- Do some work...
-- UPDATE products SET stock = stock - 1 WHERE product_id = 1;
-- ROLLBACK; OR COMMIT;

FOR UPDATE: Vad händer?

Det föregående kodexemplet visar hur FOR UPDATE fungerar. Om ni körde SELECT i session 1 och sedan omedelbart försökte köra denna UPDATE i en annan session, session 2, skulle session 2 vänta tills session 1 antingen kör COMMIT eller ROLLBACK.

Session 2 (kommer att vänta):

UPDATE products SET price = 10.99 WHERE product_id = 1;

Explicita lås: FOR SHARE

Vad gör ni om ni vill förhindra uppdateringar men tillåta att andra transaktioner läser data eller till och med hämtar ett eget delat lås?

SELECT ... FOR SHARE hämtar ett delat lås. Det innebär att:

  • Andra transaktioner kan läsa raderna.
  • Andra transaktioner kan hämta egna FOR SHARE-lås.
  • Andra transaktioner kan inte hämta FOR UPDATE-lås eller ändra raderna.

FOR SHARE i praktiken

Om session 1 har ett FOR SHARE-lås kan session 2 också hämta ett FOR SHARE-lås, men en FOR UPDATE- eller DML-operation på samma rad kommer att vänta.

Session 1:

BEGIN;
SELECT * FROM orders WHERE order_id = 101 FOR SHARE;
-- Do some calculations...
-- COMMIT; OR ROLLBACK;

Mer detaljerade lås: FOR NO KEY UPDATE

SELECT ... FOR NO KEY UPDATE liknar FOR UPDATE men är svagare. Det hämtar ett exklusivt lås som inte blockerar FOR KEY SHARE-lås.

Det är användbart när ni uppdaterar kolumner som inte är nycklar och inte behöver förhindra samtidiga operationer på främmande nycklar, vilka vanligtvis är mycket kortvariga.

Delade läslås: FOR KEY SHARE

SELECT ... FOR KEY SHARE är det svagaste explicita låset på radnivå. Det tillåter andra transaktioner att hämta FOR SHARE-, FOR NO KEY UPDATE- och även andra FOR KEY SHARE-lås.

Det förhindrar främst andra transaktioner från att ta bort de låsta raderna eller hämta ett exklusivt lås som skulle ändra nyckelkolumner. Det används ofta av främmande nyckel-begränsningar.

Strategi för låsningsordning

En viktig strategi för att förhindra deadlocks (där två transaktioner väntar på varandra på obestämd tid) är att alltid hämta lås på flera rader i en konsekvent ordning.

Om ni till exempel behöver låsa rader med product_id = 5 och product_id = 10 ska ni alltid låsa 5 först och sedan 10 i alla transaktioner. Då förhindras en situation där en transaktion låser 5 och sedan försöker låsa 10, medan en annan låser 10 och sedan försöker låsa 5.

Snabb kontroll: Radlås

Anta att två transaktioner körs samtidigt. Transaktion A kör SELECT * FROM users WHERE user_id = 1 FOR UPDATE;. Vad händer om transaktion B omedelbart försöker köra UPDATE users SET email = 'new@example.com' WHERE user_id = 1;?

Besvara frågan i den interaktiva lektionen

Sammanfattning: Lås på radnivå

Vi har undersökt hur PostgreSQL hanterar samtidighet med lås på radnivå:

  • Implicita lås skyddar DML-operationer.
  • FOR UPDATE tillhandahåller exklusiva radlås för ändringar.
  • FOR SHARE tillhandahåller delade lås som tillåter läsning men blockerar uppdateringar.
  • FOR NO KEY UPDATE och FOR KEY SHARE ger mer detaljerad kontroll.
  • En konsekvent ordning för när lås hämtas är en viktig strategi för att förhindra deadlocks.

Genom att behärska dessa strategier säkerställer ni att applikationen hanterar samtidiga skrivningar effektivt och tillförlitligt!

Gratis att börja

Lär dig SQL med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
22
Lektioner
88
Börja lära dig gratisVisa hela kursen

Vanliga frågor

Är lektionen ”Strategier för låsning på radnivå” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Prestandaoptimering och frågeoptimering i PostgreSQL, inklusive ”Strategier för låsning på radnivå”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Prestandaoptimering och frågeoptimering i PostgreSQL innehåller totalt 4 lektioner.

Vad lär jag mig i ”Strategier för låsning på radnivå”?

Utforska avancerade strategier för att hantera lås på radnivå och optimera samtidiga skrivningar. Ni övar på Prestandaoptimering och frågeoptimering i PostgreSQL med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Prestandaoptimering och frågeoptimering i PostgreSQL?

Du behöver inga förkunskaper. Utbildningen i Prestandaoptimering och frågeoptimering i PostgreSQL på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Strategier för låsning på radnivå”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Prestandaoptimering och frågeoptimering i PostgreSQL-lektionen?

Ja. Varje Prestandaoptimering och frågeoptimering i PostgreSQL-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Förstå lås och deadlocks
  2. Identifiera och lösa låskonkurrens
  3. Strategier för låsning på radnivå
  4. Advisory locks för samordning i applikationer
← Tillbaka till Prestandaoptimering och frågeoptimering i PostgreSQL