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 ... WHERESELECT ... 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 ... WHEREJust as for UPDATE ... WHERE
SELECT ... WHEREIn all isolation modes except SERIALIZABLERemaining 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 SERIALIZABLERemaining 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 MODERemaining threads can only read.
UPDATE and DELETE waiting for lock release
INSERT is blocked in the same way as in UPDATE ... WHERE
SELECT ... FOR UPDATESELECT ... 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