I. Introduction
MySQL locks can be divided in accordance with the scope of global locks, table locks, row lock, in which the row lock is implemented by the database engine, and not all engines provide row lock, MyISAM does not support row lock, so the article will introduce the line lock to InnoDB engine as an example to introduce the line lock.
Second, the global lock
MySQL provides global lock to lock the entire database instance.
grammar:
FLUSH TABLES WITH READ LOCK
This statement is generally used for backup when the implementation of this statement, all open database tables will be closed, and all global read lock to lock the database tables, while the other thread update statement (additions and deletions), data Definition Language (built table, modify table structure) and submit the transaction to update the class are blocked.
After mysql 8.0, for backup, mysql can directly use the backup lock.
Statement:
LOCK INSTANCE FOR BACKUP UNLOCK INSTANCE
The role of the lock wider range, this lock prevents the file was created, rename, delete, including REPAIR TABLE TRUNCATE TABLE, OPTIMIZE TABLE operations and management accounts will be blocked. Of course, these operations for memory temporary table that can be performed is why memory table without these restrictions? Because the memory table does not require a backup, so it is not necessary to meet these conditions.
Third, table locks
Mysql table level lock is divided into two categories, one is a lock metadata (Metadata Lock, MDL), one is a table lock.
Metadata lock (MDL) no explicit use is automatically added when accessing a table. This feature requires MySQL5.5 version will support more than when on a table to do CRUD time, the table will be added to MDL read lock; do when the table structure changes, plus MDL write lock. MDL lock There are some rules:
Not mutually exclusive read lock, so you can multi-threaded multi-table with a CRUD.
Read-write locks, write locks are mutually exclusive between, in order to ensure the safety of the table structure changes, so if you want multiple threads on the same table plus table structure and other field operations, will become serialized, we need to wait for a lock .
MDL的写锁优先级比MDL读锁的优先级，但是可以设置max_write_lock_count系统变量来改变这种情况，当写锁请求超过这个变量设置的数后，MDL读锁的优先级会比MDL写锁的优先级高。（默认情况下，这个数字会很大，所以不用担心写锁的优先级下降）
MDL的锁释放必须要等到事务结束才会释放
所以我们在操作数据库表结构时候必须要注意不要使用长事务，这里具体是什么意思呢？我举个例子说明下：
上图表示演示了4个session执行语句，首先SessionA开启了事务没有提交，接着sessionB执行查询，因为是获取MDL读锁，所以互相不影响，可以正常执行，SessionC新增一个字段，由于MDL写和读是互斥的，所以SessionC会被阻塞，之后SessionD开始执行一个查询语句，由于SessionC的阻塞，所以SessionD也阻塞了。所以，我们模拟的SessionA的事务是长事务，然后后面执行了修改表结构，会导致后续对该表所有的读写操作都不可行了。所以在实际场景中，如果业务请求比较频繁的时候，对表结构进行修改的时候就有可能导致该库的线程被阻塞满。
表锁 的语法如下：
LOCK TABLES
tbl_name [[AS] alias] lock_type
[, tbl_name [[AS] alias] lock_type] ...
lock_type: {
READ [LOCAL]
| [LOW_PRIORITY] WRITE
}
UNLOCK TABLES
表锁分为读锁和写锁，读锁不互斥，但是获取读锁不能写入数据,其他没有获取到读锁的session也是可以读取表的，所以读锁的目的就是限制表被写。如果表被读锁锁住后，再执行插入语句会报错，报错如下：
1099 - Table 'XXXX' was locked with a READ lock and can't be updated
写锁被获取后可以对表进行读写，写锁是互斥的，一旦某个session获取到表的写锁，另外的session无法访问这个表，直到写锁被释放。
表的解锁可以使用unlock tables解锁，也可以客户端口自动解锁。lock tables锁表会独占式的锁住表，除了限制其他线程对该表的读写，也会限制本线程接下来的操作对象。
四、行锁(InnoDB)
MySQL的行锁是在引擎层面实现的，所以这里讨论的也是InnoDB引擎下的行锁，下面会详细介绍InnoDB下常见的几种行锁
4.1 共享锁
共享锁能允许事务获取到锁后进行读操作，共享锁是不互斥的，一个事务获取到共享锁后，另外一个事务也可以获取共享锁，获取共享锁后不能进行写操作。
4.2 排它锁
排他锁允许事务获取到锁后进行更新一行或者删除某一行操作，排他锁顾名思义是互斥的，一个事务获取到排他锁后，其他事务不能获取到排他锁，直到这个锁被释放。
4.3 意向锁
InnoDB支持多种粒度的锁，允许行锁和表锁共存，这里说的意向锁其实是一种表级别的锁，但是我把它放在行锁里面是因为它不会单独存在，它的出现肯定会伴随着行锁（共享锁或者排他锁），它主要的目的就是表示将要锁定表中的行或者正在锁定表中的行。
意向锁根据和行锁的组合可以分为：
意向排他锁：表明将要在表中的某些行获取排他锁
意向共享锁：表明将要在表中的某些行获取共享锁
Intent locks must be acquired before the row lock acquisition, that must first acquire a shared intent to obtain locks before a shared lock for an exclusive lock is the same reason.
Then the intent locks in the end what effect?
Before explaining this, let's take a look at the intent compatible relationship before and row locks:
--- exclusive lock (X) intent exclusive locks (IX) shared lock (S) intent shared lock (IS) exclusive lock (X) conflict conflict conflict conflict intent exclusive locks (IX) conflict compatible conflict compatible shared lock (S) conflict conflict compatible compatible intent shared lock (IS) compatible compatible compatible conflict
We assume that there are two transaction A and transaction B, the transaction to acquire a shared lock, locked in a row in the table, this line can only read, can not write, now want to apply write transaction B locks the whole table. If the transaction B application is successful, then it is surely possible to table all the rows write, then certainly with the acquisition of A row locking conflict. Database To avoid this conflict will be collision detection, how to detect it? There are two ways:
Determine whether the table has been locked by other transactions with table-level locking.
Determining whether each row in the table row lock is locked.
Each row in the table to determine the need to traverse all the records, poor efficiency, so the database can do collision detection with the first approach, the intention is to use the lock.
to sum up
This article from the locking range to analyze the MySQL lock MySQL, MySQL can be divided into global lock table lock, the lock according to the line lock range. Global and table locks are to achieve their own MySQL, row locks are to achieve by the engine level. InnoDB row lock case is divided into shared locks and exclusive locks. After a shared lock request, the line can only be read, not mutually exclusive, shared locks. After obtaining an exclusive lock can update and delete rows, exclusive lock and other locks are mutually exclusive. Finally, I mentioned on the basis of the line lock lock intent, intent lock the main lock said it is about to lock the line or lines, in order to improve the detection efficiency in the lock conflict. Of course, these are not within the scope of this paper to explore if students own research interests may have other locks, such as the gap locks, record locks, Next-Key lock under InnoDB.