PricingLoginStart free
PostgreSQL Performance & Query Optimization · Lezione

Strategie di locking a livello di riga

Esplori strategie avanzate per gestire i lock a livello di riga e ottimizzare le scritture concorrenti.

Lezione 3 di 412 passaggi

Strategie di locking a livello di riga è una lezione PostgreSQL Performance & Query Optimization gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento PostgreSQL Performance & Query Optimization, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso PostgreSQL Performance & Query Optimization include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

Why Row-Level Locking?

When multiple users or processes try to change the same data at the same time, databases need a way to prevent conflicts and ensure data integrity. This is where row-level locking comes in.

A row-level lock allows a transaction to claim exclusive or shared access to specific rows, preventing other transactions from making conflicting changes until the lock is released. It's crucial for high-concurrency applications.

Implicit Row Locks

PostgreSQL automatically applies row-level locks during Data Manipulation Language (DML) operations like INSERT, UPDATE, and DELETE.

  • INSERT: Places an exclusive lock on the newly inserted row.
  • UPDATE: Places an exclusive lock on the row being modified.
  • DELETE: Places an exclusive lock on the row being deleted.

These implicit locks ensure that only one transaction can modify a specific row at a time.

Explicit Locks: FOR UPDATE

Sometimes you need to lock rows before modifying them, especially when your application logic involves reading data, making decisions, and then updating. This is where SELECT ... FOR UPDATE is invaluable.

It acquires an exclusive lock on the selected rows, preventing other transactions from updating or deleting them until your transaction commits or rolls back.

FOR UPDATE in Action

Try this example. If you run SELECT ... FOR UPDATE in one database session, then try to UPDATE the same row from another session, the second session will wait.

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: What Happens

The previous code snippet shows how FOR UPDATE works. If you ran the SELECT in Session 1, then immediately tried to run this UPDATE in a different Session 2, Session 2 would wait until Session 1 either COMMITs or ROLLBACKs.

Session 2 (will wait):

UPDATE products SET price = 10.99 WHERE product_id = 1;

Explicit Locks: FOR SHARE

What if you want to prevent updates, but allow other transactions to read the data or even acquire their own shared lock?

SELECT ... FOR SHARE acquires a shared lock. This means:

  • Other transactions can read the rows.
  • Other transactions can acquire their own FOR SHARE locks.
  • Other transactions cannot acquire FOR UPDATE locks or modify the rows.

FOR SHARE in Action

If Session 1 holds a FOR SHARE lock, Session 2 can also acquire a FOR SHARE lock, but a FOR UPDATE or DML operation on the same row will wait.

Session 1:

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

More Granular Locks: FOR NO KEY UPDATE

SELECT ... FOR NO KEY UPDATE is similar to FOR UPDATE but is weaker. It acquires an exclusive lock that doesn't block FOR KEY SHARE locks.

It's useful when you're updating non-key columns and don't need to prevent concurrent foreign key operations, which are typically very short-lived.

Shared Read Locks: FOR KEY SHARE

SELECT ... FOR KEY SHARE is the weakest explicit row-level lock. It allows other transactions to acquire FOR SHARE, FOR NO KEY UPDATE, and even other FOR KEY SHARE locks.

It primarily prevents other transactions from deleting the locked rows or acquiring an exclusive lock that would modify key columns. It's often used by foreign key constraints.

Locking Order Strategy

A critical strategy to prevent deadlocks (where two transactions wait for each other indefinitely) is to always acquire locks on multiple rows in a consistent order.

For example, if you need to lock rows with product_id = 5 and product_id = 10, always lock 5 first, then 10 across all transactions. This prevents a scenario where one transaction locks 5 then tries for 10, while another locks 10 then tries for 5.

Quick Check: Row Locks

Consider two concurrent transactions. Transaction A runs SELECT * FROM users WHERE user_id = 1 FOR UPDATE;. What happens if Transaction B immediately tries to run UPDATE users SET email = 'new@example.com' WHERE user_id = 1;?

Rispondi nella lezione interattiva

Recap: Row-Level Locks

We've explored how PostgreSQL manages concurrency with row-level locks:

  • Implicit locks protect DML operations.
  • FOR UPDATE provides exclusive row locks for modifications.
  • FOR SHARE provides shared locks, allowing reads but blocking updates.
  • FOR NO KEY UPDATE and FOR KEY SHARE offer more granular control.
  • Consistently ordering lock acquisition is a key strategy to prevent deadlocks.

Mastering these strategies ensures your application handles concurrent writes efficiently and reliably!

Gratis per iniziare

Impara SQL con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi
22
Lezioni
88
Inizia a imparare gratisVisualizza il corso completo

Domande Frequenti

La lezione «Strategie di locking a livello di riga» è gratuita?

Sì — il testo completo di «Strategie di locking a livello di riga» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso PostgreSQL Performance & Query Optimization, passa a CoddyKit PRO. Il corso PostgreSQL Performance & Query Optimization include 4 lezioni in totale.

Cosa imparerò in «Strategie di locking a livello di riga»?

Esplori strategie avanzate per gestire i lock a livello di riga e ottimizzare le scritture concorrenti. Eserciti PostgreSQL Performance & Query Optimization con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare PostgreSQL Performance & Query Optimization?

Non è richiesta alcuna esperienza precedente. PostgreSQL Performance & Query Optimization su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Strategie di locking a livello di riga»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione PostgreSQL Performance & Query Optimization?

Sì. Ogni lezione PostgreSQL Performance & Query Optimization include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Comprendere lock e deadlock
  2. Identificare e risolvere la contesa sui lock
  3. Strategie di locking a livello di riga
  4. Advisory lock per coordinare le applicazioni
← Torna a PostgreSQL Performance & Query Optimization