📜 ⬆️ ⬇️

Interlocks in InnoDB (cheat sheet)

I decided to look into the lock issue in InnoDB. The result is such a brief cheat sheet. Maybe someone will come in handy. I would be grateful to the community for the inaccuracies found

And so, within a single transaction, after ...

UPDATE ... WHERE

SELECT ... WHERE is performed without blocking (except for reads in the SERIALIZABLE isolation mode)
SELECT ... LOCK IN SHARE MODE waits for lock release
SELECT ... FOR UPDATE waits for lock release
UPDATE and DELETE waiting for lock release
')
If UPDATE ... WHERE was executed in the REPEATABLE READ or SERIALIZABLE isolation mode and the strings were not selected using a unique key, then INSERT into this key (so-called NEXT-KEY LOCK) is also blocked, but with READ COMMITTED and READ UNCOMMITTED such a lock does not occur

DELETE FROM ... WHERE

Just as for UPDATE ... WHERE

SELECT ... WHERE

In all isolation modes except SERIALIZABLE

Remaining threads can read and write / delete.
INSERT is blocked in the same way as in UPDATE ... WHERE

With REPEATABLE READ, the buffer is read and all subsequent calls return the same result.
With READ COMMITED and READ UNCOMMITTED, each request returns a fresh result (after completion of the transaction by another thread)

In isolation mode SERIALIZABLE

Remaining threads can only read (except SELECT ... FOR UPDATE reads)
UPDATE and DELETE waiting for lock release
INSERT is blocked in the same way as in UPDATE ... WHERE

SELECT ... LOCK IN SHARE MODE

Remaining threads can only read.
UPDATE and DELETE waiting for lock release
INSERT is blocked in the same way as in UPDATE ... WHERE

SELECT ... FOR UPDATE

SELECT ... WHERE can read (except for SERIALIZABLE isolation reads)
SELECT ... LOCK IN SHARE MODE and SELECT ... FOR UPDATE are waiting for the lock to be released
UPDATE and DELETE waiting for lock release
INSERT is blocked in the same way as in UPDATE ... WHERE

Source: https://habr.com/ru/post/150075/


All Articles