Strategier for row-level locking
Udforsk avancerede strategier til håndtering af row-level locks for at optimere samtidige skrivninger.
Strategier for row-level locking er en gratis Ydelsesoptimering og optimering af forespørgsler i PostgreSQL-lektion på CoddyKit. Dette er lektion 3 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.
Hvorfor låsning på rækkeniveau?
Når flere brugere eller processer forsøger at ændre de samme data på samme tid, har databaser brug for en måde at forhindre konflikter og sikre dataintegriteten på. Det er her, låsning på rækkeniveau kommer ind i billedet.
En lås på rækkeniveau giver en transaktion eksklusiv eller delt adgang til bestemte rækker og forhindrer andre transaktioner i at foretage modstridende ændringer, indtil låsen frigives. Det er afgørende for applikationer med høj samtidighed.
Implicitte rækkelåse
PostgreSQL anvender automatisk låse på rækkeniveau under Data Manipulation Language-operationer (DML) som INSERT, UPDATE og DELETE.
INSERT: Placerer en eksklusiv lås på den netop indsatte række.UPDATE: Placerer en eksklusiv lås på den række, der ændres.DELETE: Placerer en eksklusiv lås på den række, der slettes.
Disse implicitte låse sikrer, at kun én transaktion ad gangen kan ændre en bestemt række.
Eksplicitte låse: FOR UPDATE
Nogle gange har du brug for at låse rækker, før du ændrer dem, især når applikationslogikken indebærer, at data læses, der træffes beslutninger, og data derefter opdateres. Her er SELECT ... FOR UPDATE uvurderlig.
Den erhverver en eksklusiv lås på de valgte rækker og forhindrer andre transaktioner i at opdatere eller slette dem, indtil din transaktion gennemfører eller ruller tilbage.
FOR UPDATE i praksis
Prøv dette eksempel. Hvis du kører SELECT ... FOR UPDATE i én databasesession og derefter forsøger at køre UPDATE på den samme række fra en anden session, vil den anden session vente.
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: Hvad sker der?
Det foregående kodestykke viser, hvordan FOR UPDATE fungerer. Hvis du kørte SELECT i session 1 og derefter straks forsøgte at køre denne UPDATE i en anden session, ville session 2 vente, indtil session 1 enten udfører COMMIT eller ROLLBACK.
Session 2 (venter):
UPDATE products SET price = 10.99 WHERE product_id = 1;Eksplicitte låse: FOR SHARE
Hvad nu, hvis du vil forhindre opdateringer, men tillade, at andre transaktioner læser dataene eller endda erhverver deres egen delte lås?
SELECT ... FOR SHARE erhverver en delt lås. Det betyder:
- Andre transaktioner kan læse rækkerne.
- Andre transaktioner kan erhverve deres egne
FOR SHARE-låse. - Andre transaktioner kan ikke erhverve
FOR UPDATE-låse eller ændre rækkerne.
FOR SHARE i praksis
Hvis session 1 har en FOR SHARE-lås, kan session 2 også erhverve en FOR SHARE-lås, men en FOR UPDATE- eller DML-operation på den samme række vil vente.
Session 1:
BEGIN;
SELECT * FROM orders WHERE order_id = 101 FOR SHARE;
-- Do some calculations...
-- COMMIT; OR ROLLBACK;Mere detaljerede låse: FOR NO KEY UPDATE
SELECT ... FOR NO KEY UPDATE minder om FOR UPDATE, men er svagere. Den erhverver en eksklusiv lås, som ikke blokerer FOR KEY SHARE-låse.
Den er nyttig, når du opdaterer kolonner, der ikke er nøgler, og ikke behøver at forhindre samtidige fremmednøgleoperationer, som typisk varer meget kort tid.
Delte læselåse: FOR KEY SHARE
SELECT ... FOR KEY SHARE er den svageste eksplicitte lås på rækkeniveau. Den tillader, at andre transaktioner erhverver FOR SHARE-, FOR NO KEY UPDATE- og endda andre FOR KEY SHARE-låse.
Den forhindrer primært andre transaktioner i at slette de låste rækker eller erhverve en eksklusiv lås, der ville ændre nøglekolonner. Den bruges ofte af fremmednøglerestriktioner.
Strategi for låserækkefølge
En vigtig strategi til at forhindre deadlocks (hvor to transaktioner venter på hinanden i det uendelige) er altid at erhverve låse på flere rækker i en ensartet rækkefølge.
Hvis du f.eks. skal låse rækker med product_id = 5 og product_id = 10, skal du altid låse 5 først og derefter 10 i alle transaktioner. Det forhindrer en situation, hvor én transaktion låser 5 og derefter forsøger at låse 10, mens en anden låser 10 og derefter forsøger at låse 5.
Hurtig test: rækkelåse
Forestil dig to samtidige transaktioner. Transaktion A kører SELECT * FROM users WHERE user_id = 1 FOR UPDATE;. Hvad sker der, hvis transaktion B straks forsøger at køre UPDATE users SET email = 'new@example.com' WHERE user_id = 1;?
Opsummering: låse på rækkeniveau
Vi har undersøgt, hvordan PostgreSQL håndterer samtidighed med låse på rækkeniveau:
- Implicitte låse beskytter DML-operationer.
FOR UPDATEgiver eksklusive rækkelåse til ændringer.FOR SHAREgiver delte låse, som tillader læsning, men blokerer opdateringer.FOR NO KEY UPDATEogFOR KEY SHAREgiver mere detaljeret kontrol.- En ensartet rækkefølge for erhvervelse af låse er en vigtig strategi til at forhindre deadlocks.
Når du behersker disse strategier, kan din applikation håndtere samtidige skrivninger effektivt og pålideligt!
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 “Strategier for row-level locking” gratis?
Ja — alle 3 lektioner i læringssporet Ydelsesoptimering og optimering af forespørgsler i PostgreSQL, inklusive “Strategier for row-level locking”, 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 “Strategier for row-level locking”?
Udforsk avancerede strategier til håndtering af row-level locks for at optimere samtidige skrivninger. 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 3 af 4.
Hvor lang tid tager lektionen “Strategier for row-level locking”?
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
- Forståelse af locks og deadlocks
- Identifikation og løsning af lock contention
- Strategier for row-level locking
- Advisory locks til koordinering i applikationer