Row, table, page, share, exclusive, pessimistic, optimistic, deadlock

Why lock up ?

Ensure database integrity and consistency in multi-user environment .

When multiple users access data concurrently , In the database, there will be multiple transactions accessing the same data at the same time . If you do not control the concurrent operation, you may read and store incorrect data , Breaking database consistency .

---

Classification of locks

1. Classify according to particle size

MyISAM Use watch level lock (table-level locking).
InnoDB Row level locking is supported (row-level locking) And watch level locks , The default is row level lock

Row-level locks

1. The line lock is MySQL The lock with the finest granularity , Indicates that only the row of the current operation is locked . Row level lock can greatly reduce the conflict of database operation . The lock granularity is the smallest , But locking costs the most . Row level locks are divided into shared locks and Exclusive lock .

2. Spending big , Lock the slow ; A deadlock occurs ; Locking granularity minimum , The lowest probability of lock collisions , The highest degree of concurrency .

Table lock

1. The watch lock is MySQL The lock with the largest granularity , Indicates to lock the whole table of the current operation , It's easy to implement , Less resource consumption , By most MySQL Engine support . Most commonly used MYISAM And INNODB Table level locking is supported . Table level locks are divided into table shared read locks （ Shared lock ） Write lock exclusive to table （ Exclusive lock ）.

2. Low overhead , Locked fast ; A deadlock will not occur ; Large locking size , The highest probability of lock conflict is , Lowest degree of concurrency .

Page level lock

1. Page level lock is MySQL A lock whose granularity is between row level lock and table level lock . The watch lock is fast , But there are many conflicts , Less line level conflict , But the speed is slow. . So I took a compromise page level , Lock an adjacent set of records at a time .BDB Support page level lock

2. Cost and lock time are between table lock and row lock ; A deadlock occurs ; Lock granularity is between table lock and row lock , The concurrency is average

2. Category

Shared lock and exclusive lock

Shared lock :

It's also called read lock . When the user wants to read the data , Add a shared lock to the data . A shared lock can have more than one .

Exclusive lock :

Also called write lock . When the user wants to write data , Add an exclusive lock to the data . Only one lock can be added , He's locked up with the others , Shared locks are mutually exclusive .

In the above example, there are two kinds of user behavior , One is coming to see the house , It is acceptable for multiple users to watch the house together . One is a real one night stay , in the meantime , No matter what you want to check in or what you want to see .

---

What are optimistic locks and pessimistic locks of database ？ How to achieve ？

Database management system （DBMS） The task of concurrency control in is to ensure that when multiple transactions access the same data in the database at the same time, it does not damage the isolation and unity of transactions and the unity of the database . Optimistic concurrency control （ Optimism lock ） And pessimistic concurrency control （ Pessimistic locking ） Is the main technical means of concurrency control .

Pessimistic locking ： Concurrent conflicts are assumed , Block all operations that may violate data integrity . Lock up the transaction after querying the data , Until the transaction is committed . Realization way ： Using the lock mechanism in the database

Optimism lock ： Assume no concurrency conflicts , Check for data integrity violations only when submitting operations . Lock up transactions when modifying data , adopt version To lock in the same way . Realization way ： Music usually uses the version number mechanism or CAS Algorithm implementation .

If it's more writing , There are often conflicts , This will lead to the continuous application of the upper layer retry, This, in turn, reduces performance , So it's more suitable to use pessimistic lock in general scenario .

---

InnoDB How to realize the row lock of engine ？

InnoDB It is based on the index to complete row locking

example : select * from tab_with_index where id = 1 for update;

for update The row lock can be locked according to the conditions , also id It's a column with an index key , If id Not the index key InnoDB Table lock will be completed , Concurrency will be impossible

---

What is a deadlock ？ How to solve ？

Deadlock means that two or more transactions occupy each other on the same resource , And ask to lock the other party's resources , Which leads to a vicious circle .

Common solutions to deadlock

1、 If different programs access multiple tables simultaneously , Try to agree to access tables in the same order , Can greatly reduce the chance of deadlock .

2、 In the same transaction , Try to lock all the resources you need at once , Reduce the probability of deadlock ;

3、 For business parts that are very prone to deadlock , You can try using upgrade lock granularity , Table level locking is used to reduce the probability of deadlock ;

If business processing is not good, you can use distributed transaction lock or optimistic lock

---

The relationship between isolation level and lock

stay Read Uncommitted Below grade , Reading data does not require a shared lock , This will not conflict with the exclusive lock on the modified data

stay Read Committed Below grade , Read operations require shared locks , But release the shared lock after the statement is executed ;

stay Repeatable Read Below grade , Read operations require shared locks , But the shared lock is not released before the transaction is committed , In other words, the shared lock must be released after the transaction is completed .

SERIALIZABLE It's the most restrictive level of isolation , Because this level locks the entire range of keys , And hold the lock all the time , Until the transaction is complete .

---

Opinions on optimizing locks ？

1. Use a lower isolation level

2. Design index , Try to use indexes to access data , Locking is more accurate , Thus reducing lock conflicts

3. Choose a reasonable transaction size , When locking the record display , It's best to request a lock of sufficient level at once . Columns such as , If you modify the data , You'd better apply for an exclusive lock , Instead of applying for a shared lock first , Apply for exclusive lock when modifying , This can lead to deadlock

4. When different programs access a set of tables , Try to agree to access the tables in the same order , For a table , Get the rows in the table in a fixed order as much as possible . This greatly reduces the chance of deadlock .

5. Try to use equal conditions to access data , This can avoid the effect of gap lock on concurrent insert

6. Don't apply for more locks than you actually need

7. Data query is not necessary , Don't use locks .MySQL Of MVCC The query in the transaction can be realized without lock , Optimize transaction performance ：MVCC Only in committed read（ Read the submission ） and repeatable read （ Repeatable ） Two isolation levels

8. For a particular transaction , Table locks can be used to improve processing speed and reduce the possibility of deadlock .