Read all locks in one article, understand their advantages, disadvantages and usage scenarios.
Table-level locks and row-level locks
Table-level lock:
Table-level locking, to lock the entire table.
The overhead is small and the lock is fast.
No deadlock (load all tables needed at once).
The lock granularity is large, the probability of lock conflicts is high, and the concurrency efficiency is low.
Suitable for queries.
Row-level lock:
row-level loking, lock a row of records.
The overhead is large and the locking is slow.
Will deadlock.
The lock granularity is small, the probability of conflicts is small, and the concurrency efficiency is high.
Suitable for concurrent writing and transaction control.
Instead of directly losing the record row and locking, it locks the index corresponding to the row:
If the sql statement manipulates the primary key index, Mysql will lock the primary key index.
If the sql statement operates a non-primary key index, MySQL will first lock the non-primary key index, and then lock the related primary key index.
In InnoDB, if the SQL statement does not involve an index, the record will be locked through the hidden clustered index.
The actual effect of locking a clustered index is the same as that of a table lock, because to find a record, the entire table must be scanned, and to scan the entire table, the table must be locked.
Engine and lock:
The MyISAM engine supports table-level locks, but does not support row-level locks.
The InnoDB engine supports table-level locks and row-level locks, and the default is row-level locks.
Shared lock and exclusive lock
Shared lock:
There are called S locks and read locks.
The current thread adds a shared lock to the shared resource, and other threads can read this resource and continue to add shared locks, but this resource cannot be modified and exclusive locks cannot be added.
语法：select id from t_table in share mode;
Multiple shared locks can coexist, shared locks and exclusive locks cannot coexist.
Exclusive lock:
Also called X lock and write lock.
The current thread adds an exclusive lock to the shared resource, other threads are not allowed to read this resource, are not allowed to add shared locks, are not allowed to modify this resource, and are not allowed to add exclusive locks.
grammar:
1. update t_table set a =1; // Add, delete and modify the database by default will add an exclusive lock
2. select * from t_table for update;// for update is also a kind of addition, deletion and modification
Exclusive locks are exclusive and will not coexist with other locks.
Optimistic and pessimistic locking
Optimistic locking and pessimistic locking are logical locks.
Optimistic lock:
Optimistic locking: optimistically believe that concurrency problems are difficult to occur.
Although optimistic locking believes that concurrency problems are difficult to occur, it is not that they do not occur. Therefore, there are measures to prevent the problem from actually occurring: each data modification automatically increments the version number version.
When data is read, the current version number version1 is not locked, but the current version number version1 is read at the same time; when the data is modified, it is necessary to judge whether the current version number version2 is equal to the previous version number version1.
The version number does not match, it means that the concurrency problem has occurred, so you need to roll back this operation.
Implementation method: version number mechanism, CAS.
Pessimistic lock:
Pessimistic lock: pessimistically believes that concurrency problems are prone to occur.
Pessimistic locking believes that concurrency problems are very easy to occur, so every operation, regardless of read or write, will lock the record to prevent other threads from modifying the data.
Implementation mode: row lock, read lock and write lock of the database.