MySQL lock usage row-level lock

    Row-level locks are the smallest granularity locks in MySQL, which can greatly reduce conflicts in database operations. But the smaller the granularity, the higher the cost of implementation. The MYISAM engine only supports table-level locks, while the INNODB engine can support row-level locks. The following content is also expanded for INNODB row-level locks.

    There are two types of row-level locks in INNODB: shared locks (S LOCK) and exclusive locks (X LOCK). Shared locks allow transactions to read a row of records and do not allow any thread to modify that row of records. An exclusive lock allows the current transaction to delete or update a row of records, and other threads cannot manipulate the record.


  Shared lock:
    Usage: SELECT ... LOCK IN SHARE MODE;

    MySQL adds a shared lock to each row in the query result set.

    Prerequisites for lock application: No thread currently uses an exclusive lock on any row in the result set, otherwise the application will be blocked.

    Operational restrictions:

Table of restrictions on locking record operations between threads using shared locks and threads that do not use shared locks

thread read operation write operation Shared lock application Exclusive lock application
use shared lock readable writable/unwritable (error) can apply can apply
Do not use shared locks readable not writable (blocking) can apply Unapplicable (blocking)

1. A thread using a shared lock can read its lock record, and other threads can also read the lock record, and the data read by these two threads belong to the same version.

2. For write operations, threads using shared locks need to be discussed on a case-by-case basis. When only the current thread uses a shared lock for a specified record, the thread can perform write operations (including update and delete) on the record. Before the write operation, the thread applies for an exclusive lock to the record, and then the write operation is performed; when other threads also use the shared lock on the record, the write operation cannot be performed, and the system will report an error message. Threads that do not use shared locks for locked records, of course, cannot perform write operations, and write operations will block.

3. The process using the shared lock can apply for a shared lock for the lock record again, and the system does not report an error, but the operation itself does not make much sense. Other threads can also apply for shared locks on locked records.

4. A process using a shared lock can apply for an exclusive lock on its lock record; other processes cannot apply for an exclusive lock on the lock record, and the application will be blocked.


  Exclusive lock:

    用法: SELECT ... FOR UPDATE;

    MySQL will add an exclusive lock to each row in the query result set. During transaction operations, any update and delete operations on records will automatically add an exclusive lock.

    Prerequisites for lock application: No thread currently uses an exclusive lock or shared lock on any row in the result set, otherwise the application will be blocked.

    Operational restrictions:

Using the exclusive lock thread and not using the exclusive lock thread on the lock record operation limit table

thread
read operation
write operation Shared lock application Exclusive lock application
use exclusive lock Readable (new version) writable can apply can apply
Do not use exclusive locks readable (old version) not writable (blocking) Unapplicable (blocked) Unapplicable (blocked)

1. A thread that uses an exclusive lock can read its lock record, and the read content is the latest version of the current thing; while for a thread that does not use an exclusive lock, the read operation can also be performed. This feature is consistent and non-consistent. Lock read. That is, for the same record, the database records multiple versions, the update operation in the transaction will be reflected in the new version, and the old version will be provided to other threads for read operations.

2. A thread that uses an exclusive lock can write to its lock record; for a thread that does not use an exclusive lock, the write operation to the lock record is not allowed, and the request will block.

3. A process using an exclusive lock can apply for a shared lock on its locked record, but after applying for a shared lock, the thread will not release the original exclusive lock, so the record exhibits the nature of an exclusive lock to the outside world; other threads cannot lock the record. Apply for a shared lock, the request will block.

4. A process using an exclusive lock can apply for an exclusive lock on its lock record (it doesn't actually make any sense); while other processes cannot apply for an exclusive lock on a lock record, the application will be blocked.

linux

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324777137&siteId=291194637