MySQL table mechanism

Understanding of lock

1.1 The explanation of the lock

A mechanism by which a computer coordinates multiple processes or threads to access a resource concurrently .

1.2 The importance of locks

In the database , In addition to traditional computing resources （CPU、RAM、I\O etc. ） Scramble for , Data is also a resource shared by multiple users . How to ensure the consistency of data concurrent access , effectiveness , It's a problem that all databases have to solve . Lock conflicts are also an important factor affecting the performance of concurrent database access , Therefore, locks are particularly important for databases .

1.3 The disadvantages of locks

Locking is resource consuming , Various operations of lock , Including getting a lock 、 Check whether the lock has been released 、 Release lock, etc , Will increase the cost of the system .

1.4 A simple example

Nowadays, online shopping has become particularly common , For example, Taobao's double 11 Events , The flow of people on that day is tens of millions and hundreds of millions , But the merchant's inventory is limited . In order to ensure that the merchant's commodity inventory is not oversold , Lock the inventory of goods . When a user is placing an order for the last piece of a product , The system will lock the commodity immediately , Prevent other users from placing repeated orders , It will not be released until the payment action is completed （ If the payment is successful, the inventory will be reduced and sold out immediately , If the payment fails, it will be released immediately ）.

The type of lock

2.1 Table locks

species

Read the lock （read lock）, Also called Shared locks （shared lock） For the same data , Multiple read operations can be performed simultaneously without affecting each other （select）（ Read locks block write operations , Does not block read operations ）

Write lock （write lock）, It's also called exclusive lock （exclusive lock） Before the current operation is completed , Will block other read and write operations （update、insert、delete）（ Write locks block read and write operations ）

Storage engine default lock

MyISAM

characteristic

1. Lock the whole watch 2. Low overhead 3. Locked fast 4. No deadlock 5. Big lock size , The probability of lock conflict is high , Low concurrency

Conclusion

1. Read locks block write operations , Does not block read operations 2. Write locks block read and write operations

Suggest

MyISAM Read and write lock scheduling is write first , This is also MyISAM It is not suitable to be an engine for writing main tables , Because after writing the lock , Other threads cannot do anything , A large number of updates make it difficult for queries to get locks , And cause permanent obstruction .

2.2 Row lock

species

Read the lock （read lock）, Also called Shared locks （shared lock） Allow a transaction to read a line , Prevent other transactions from obtaining exclusive locks for the same dataset

Write lock （write lock）, It's also called exclusive lock （exclusive lock） Allow to get transaction update data of exclusive lock , Prevent other transactions from obtaining shared and exclusive locks of the same dataset

Features storage engine default lock

InnoDB

1. Lock a row of data 2. Spending big 3. Lock the slow 4. A deadlock occurs 5. Small lock size , The probability of lock conflict is the lowest , High concurrency

The problem of transaction concurrency

1. Update missing solve ： Turn transactions into serial operations , Instead of concurrent operations , That is, start for each transaction --- Exclusive lock on read records 2. Dirty reading solve ： The isolation level is Read uncommitted 3. Don't reread solve ： Use Next-Key Lock Algorithm to avoid 4. Fantasy reading solve ： Clearance lock （Gap Lock） The problem of transaction concurrency Dirty reading Easiest to understand . Another transaction modified the data , But has not yet submitted , And in this matter SELECT You'll read the uncommitted data . If , Go to the canteen for lunch , I saw a seat was small by my classmates Q Got it , I think this seat has been occupied , Just turn around and find another seat . lo , This classmate is young Q Got up and left . The facts ： The student is young Q I just sat down temporarily , Not “ Submit ”. Don't repeat It's also two transactions operating on the same data , If you read some data at the beginning of a transaction , At this point, another transaction modifies the data , When the transaction reads this data again, it finds that it has changed , The data results read twice are inconsistent , There's no way to read a piece of data over and over again . If , Go to the canteen for lunch , See a seat is empty , He went to fetch rice , When I came back, I found that this seat was small by my classmates Q Occupied . Fantasy reading At the beginning of the transaction, no data was found according to a certain query condition , The result is due to another transaction , When I went to check again, I found the data , It's like hallucination , It's called Unreal reading . If , Go to the canteen for lunch , See a seat is empty , He went to fetch rice , After you come back , Found that these seats are still empty （ Repeated reading ）, Steal joy . When I came to the front and was just about to sit down , But there was a dinosaur girl , Seriously affect appetite . It seems that the empty seat I saw before is “ The phantom ” equally .

2.3  Four isolation levels of transactions

MySQL InnoDB There are four levels of transaction isolation , The default is “ Repeatable ”（REPEATABLE READ）.

Uncommitted read （READ UNCOMMITTED）

Read uncommitted means that a transaction can be read without being committed , Obviously, this isolation level will lead to reading other uncommitted data , Once further processing is done based on the data read , Another transaction eventually rolls back the operation , Then the data will be messed up , And it's hard to track . On the whole , Reading uncommitted levels results in dirty reads .

Another transaction modified the data , But has not yet submitted , And in this matter SELECT You'll read the uncommitted data （ Dirty reading ）.

Submit to read （READ COMMITTED）

Must be submitted before reading , Suppose you take a bank card to spend , Before you pay, you see that Cary has 2000 element , Your wife is shopping on Taobao at this time , I finished the payment ahead of you , At this time, when you pay again, you will be prompted that the balance is insufficient , But you can see that the money in the card is enough .

This is when two transactions are executed , Business A I read it at the beginning. The card has 2000 element , This is the time for business B Spend all the money on the card , Business A When we finally reconfirmed the balance, we found that the card had no money . Obviously , Read submit can solve the dirty read problem , But it can't be repeated .

This transaction reads the latest data （ After other transactions are committed ）. The problem is , In the same business , Two times the same SELECT You'll read different results （ Don't repeat ）.

（ Default ） Repeatable （REPEATABLE READ）

Solve the problem of non repeatable reading , Business A Once the execution starts , Regardless of business B How to change the data , Business A What you always read is the value it just started reading . So here's the problem , What if B hold id by 1 The data in the table is changed to 2, Business A Don't know id There is a change , When a transaction A When we added new data, we found that 2 Of id It already exists , This is unreal reading .

In the same business ,SELECT The result is a point in time state at the start of the transaction , therefore , alike SELECT The results read by the operation will be consistent . however , There will be unreal reading （ Fantasy reading ）.

Serialization （SERIALIZABLE）

All the transactions are executed one by one , Because there is no concurrent scenario , What kind of unreal reading 、 Dirty reading 、 It's not repeatable. It doesn't exist . But again , Basic concurrency will be very poor .

The read operation implicitly acquires the shared lock , It can ensure the mutual exclusion between different transactions .

How to lock ？

3.1 Table locks

Implicit locking （ Default , Automatic locking and automatic release ）

select // Up reading lock

insert、update、delete // Write up lock

Explicit locking （ Manual ）

lock table tableName read;// Read the lock lock table tableName write;// Write lock

Unlock （ Manual ）

unlock tables;// All lock tables

session01	session02
lock table teacher read;// Up reading lock
select * from teacher; // It can be read normally	select * from teacher;// It can be read normally
update teacher set name = 3 where id =2;// An error is reported because the read lock is locked and the write operation cannot be performed	update teacher set name = 3 where id =2;// Blocked
unlock tables;// Unlock
	update teacher set name = 3 where id =2;// Update operation successful

session01	session02
lock table teacher write;// Write up lock
select * from teacher; // It can be read normally	select * from teacher;// Blocked
update teacher set name = 3 where id =2;// You can update the operation normally	update teacher set name = 4 where id =2;// Blocked
unlock tables;// Unlock
	select * from teacher;// Read successful
	update teacher set name = 4 where id =2;// Update operation successful

3.2 Row lock

Implicit locking （ Default , Automatic locking and automatic release ）

select // It won't lock

insert、update、delete // Write up lock

Explicit locking （ Manual ）

select * from tableName lock in share mode;// Read the lock select * from tableName for update;// Write lock

Unlock （ Manual ）

1. Commit transaction （commit） 2. Roll back the transaction （rollback） 3. kill Blocking process

session01	session02
begin;
select * from teacher where id = 2 lock in share mode;// Up reading lock
	select * from teacher where id = 2;// It can be read normally
update teacher set name = 3 where id =2;// You can update the operation	update teacher set name = 5 where id =2;// Blocked
commit;
	update teacher set name = 5 where id =2;// Update operation successful

session01	session02
begin;
select * from teacher where id = 2 for update;// Write up lock
	select * from teacher where id = 2;// It can be read normally
update teacher set name = 3 where id =2;// You can update the operation	update teacher set name = 5 where id =2;// Blocked
rollback;
	update teacher set name = 5 where id =2;// Update operation successful

Why is it locked , Other transactions can also be read ？ because InnoDB Yes MVCC Mechanism （ Multi version concurrency control ）, You can use a snapshot to read , Without being blocked .

4  Precautions for row lock

1. Only when retrieving data through index criteria ,InnoDB To use row level locks , Otherwise, table level locks will be used ( Index failure , Row lock changes table lock ) 2. Even accessing records from different peers , If the same index key is used , Lock conflicts occur 3. If the data table has multiple indexes , You can lock different rows through different indexes

How to check the lock ？

5.1 Table locks

Check the table lock

1	show open tables;

Table lock analysis

1	show status like 'table%';

1. table_locks_waited The number of waits for table level lock contention （ The number of times a lock cannot be acquired immediately , Add... To each waiting value 1）, A high value indicates that there is a serious table level lock contention 2. table_locks_immediate Number of table level locks generated , Not the number of queries that can acquire locks immediately , Every time you get the lock immediately 1

5.2 Row lock

Line lock analysis

1	show status like 'innodb_row_lock%';

1. innodb_row_lock_current_waits // The number of currently waiting locks 2. innodb_row_lock_time // The total length of time from system startup to lock up 3. innodb_row_lock_time_avg // The average time it takes to wait 4. innodb_row_lock_time_max // The longest waiting time from system startup to now 5. innodb_row_lock_waits // The total number of times the system has been waiting since it was started

Deadlock

6.1 explain

It means that two or more transactions occupy each other on the same resource , And request to lock the resources occupied by the other party , Which leads to a vicious circle

6.2 The conditions of production

1. mutual exclusion ： A resource can only be used by one process at a time 2. Request and hold conditions ： When a process is blocked by a request for resources , Keep the acquired resources 3. Conditions of non deprivation ： Resources obtained by the process , Before it's used up , Can't be forcibly deprived 4. Loop wait condition ： Multiple processes form a relationship of resources waiting for each other in a cycle

6.1 solve

1. Look at deadlocks ：show engine innodb status \G 2. Automatic detection mechanism , Timeout automatically rolls back less expensive transactions （innodb_lock_wait_timeout Default 50s） 3. Artificially solve ,kill Blocking process （show processlist） 4. wait for graph Waiting chart （ Active detection ）

6.1 How to avoid

1. Lock in the same order , Try to lock the required data rows at one time 2. Try to be based on primary（ Primary key ） or unique key Update data 3. The amount of data in a single operation should not be too much , Involve as few tables as possible 4. Reduce the index on the table , Reduce locking resources 5. Try to use a lower isolation level 6. Try to use the same conditions to access data , This can avoid the impact of gap lock on concurrent insertion 7. Well designed index , Try to use indexes to access data 8. With the help of relevant tools ：pt-deadlock-logger

Optimistic lock and pessimistic lock

7.1 Pessimistic locking

explain

Concurrent conflicts are assumed , Block all operations that may violate data integrity

Implementation mechanism

Table locks 、 Line lock, etc

Implementation level

The database itself

Applicable scenario

There's a lot of concurrency

7.2 Optimism lock

explain

Assume no concurrency conflicts , Check for data integrity violations only when submitting operations

Implementation mechanism

When submitting an update, check whether the version number or timestamp conforms to

Implementation level

Business code

Applicable scenario

The amount of concurrency is small

8.select … for update Inquire about
select Queries are unlocked ,select…for update It will be locked , And it's a pessimistic lock , But the types of locks that are added in different query conditions （ Row lock , Table locks ） Is different .

select * from t_user where id = 1 for update;

Cause ：
stay where The following query criteria are the primary key index , The only index is the row lock
When the query condition is a common field, a table lock is added

9. Commands that are easy to forget

1. Open transaction ：start transaction ;
2. Pessimistic locking ：select user_id ,user_name from huixin where user_id=1002 for update ;
3. Commit transaction ： commit ;
4. View the current lock ：show open tables where In_use >0;
5. Clear all locks ：unlock tables;
6. Set the commit of the transaction ：set autocommit = (off/0) or set autocommit =( on/1)
7. Check whether the transaction is automatically committed ： show variables like ‘autocommit’
8. Roll back the transaction ：rollback