Common locks in MySQL

The purpose of locking is to ensure that shared resources at any time , Only one thread accesses , In this way, we can avoid the problem of data sharing disorder caused by multithreading .

classification ：

Press Granularity of operational data classification ： Global lock 、 Table lock 、 Row lock

Press The type of data operation classification ：

1. Pessimistic locking ： Read the lock （ Shared lock ）, Write lock （ Exclusive lock ） Does not support concurrency ;
2. Optimism lock ： Support multithreading and concurrency , Transactions do not need to be queued , This data can be modified , However, the data needs to have a version number , Only when the version numbers before and after modification are consistent can the modification be successful , Otherwise, it will roll back .（ Modify first and then verify ） , Such as online documents
   Only when the probability of conflict is very low , And the locking cost is very high , Just consider using optimistic lock .

Press Level of lock classification ：

1. Advanced lock ： Read the lock 、 Write lock
2. Low level lock ： The mutex 、 spinlocks （ It's all pessimistic ）

High level locks are implemented by low-level locks , For example, the read-write lock can be implemented with mutex , It can also be implemented based on spin lock .

1. Global lock

After execution , The entire database is read-only ,DQL Query available ,DML and DDL Unavailable .

scene ：

Global lock is mainly used for full database logical backup , In this way, the data or table structure will not be updated , The data of the backup file is different from the expected situation .

shortcoming ： The granularity is too large , Cause business stagnation

locked ：flush tables with read lock;
Unlock ：unlock tables;

2. Table locks

InnoDb and MyISAM All support ; Low overhead , Locked fast , Large grain size , High probability of conflict , Low concurrency ;

locked ：
lock tables Table name read; （ Read the lock ）
lock tables Table name weite; （ Write lock ）

Unlock ：
unlock tables;

Be careful ： When reading lock , The table cannot be written in the locked session （DML、DDL） operation

3. Row lock

InnoDb Row level lock is supported ,MyISAM I won't support it , Spending big , Lock the slow , Small particle size , The probability of conflict is low , High concurrency ;

locked ：
select... where... lock in share mode;
select... where... for update;

3. Mutexes and spinlocks

When a thread is already locked , Locking other threads will fail , Mutexes and spinlocks have different ways to handle lock failures ：

• After the mutex locking fails , The thread will release CPU , To other threads ;
• After the spin lock fails to lock , The thread is busy waiting , Until it gets the lock ;

The mutex ：
Mutex is a kind of 「 An exclusive lock 」, For example, when a thread A After locking successfully , At this point, the mutex has been locked by the thread A Exclusive , Just threads A No release of the lock in your hand , Threads B Locking will fail , And then it will release CPU Give way to other threads , Since threads B Released CPU, Natural threads B The locked code will be blocked .
For mutex locking failure and blocking phenomenon , It's implemented by the operating system kernel . When the lock fails , The kernel will set the thread to 「 sleep 」 state , When the lock is released , The kernel wakes up threads at the right time , When the thread successfully acquires the lock , So you can go on with it . therefore , When mutex locking fails , From user mode to kernel state , Let the kernel switch threads for us , Although it simplifies the difficulty of using locks , But there are some performance overhead costs .

spinlocks ：
When using spinlocks , When a multi thread contention lock occurs , A thread that fails to lock will 「 Busy waiting 」,
Spin lock is the simplest kind of lock , Always spin , utilize CPU cycle , Until the lock is available ,
But if the locked code takes too long to execute , Spinning threads take up for a long time CPU resources ,

Compare ：
The use level of spin lock and mutex lock is similar , But the implementation level is completely different ： When the lock fails , Mutex uses 「 Thread switching 」 Coping with , Spin locks use 「 Busy waiting 」 Coping with .

Both of them are the most basic ways to handle locks , More advanced locks will choose one of them to implement , For example, the read-write lock can be implemented with mutex , It can also be implemented based on spin lock ,

scene ：
If the mutex fails to lock, the thread will be switched to deal with , It will increase the cost ; If the execution time of the locked code is short , You should choose spin lock , Busy waiting time is also short , Low overhead ;

Reference resources ：
https://blog.csdn.net/qq_34827674/article/details/108608566
https://xiaolincoding.com/mysql/lock/mysql_lock.html#%E5%85%A8%E5%B1%80%E9%94%81