1.什么是锁
锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中，数据是供许多用户共享的资源，数据库必须保证数据并发访问的一致性、有效性，这就要靠锁来协调实现。
MySOL中的锁，分为以下三类：
（1）全局锁：锁定数据库中的所有表
（2）表级锁：每次操作锁住整张表
（3）行级锁：每次操作锁住对应的行数据
2.全局锁
2.1全局锁的作用
全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态（DML、DDL不可执行，DQL可执行）已经更新操作的事务提交语句都将被阻塞。
其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，保证数据的完整性、一致性。
数据库的备份是逐表进行的，可能刚刚完成了A表的备份，与A表相关的B表又更新了数据，造成了数据的不一致，因此备份前要加上全局锁
2.2实例备份
2.2.1使用全局锁的方法
（1）先进入数据库，通过以下命令创建全局锁：
flush tables with read lock;
（2）创建全局锁后，退出数据库，在windows或linux的命令行界面使用以下命令进行备份：
mysqldump -u登录数据库的用户 -p密码 数据库名>文件名
#-u与-p和后面的内容之间是没有空格的
#命令中的文件名，指的就是数据被复制后，存储到了这个文件里
#如果操作的不是本地数据库，而是远程连接的，那么就需要在命令里加上 -h 远程数据库ip
（3）备份完成后，再进入数据库，输入以下命令解开全局锁：
unlock tables;
2.2.2不使用全局锁的方法
由于数据库中加全局锁是一个比较重的操作，且存在以下问题:
（1）如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆。
（2）如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志(binlog)，会导致主从延迟
因此实际生产中要慎用全局锁。
在InnoDB引擎环境下，还有一种不使用全局锁实现一致性备份数据库的方法，只需在mysqldump命令里添加一个参数即可：
mysqldump --single-transaction -u登录数据库的用户 -p密码 数据库名>文件名
#注意--single-transaction没有空格
3.表级锁
表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。
对于表级锁，主要分为以下三类:
（1）表锁
（2）元数据锁(meta data lock，MDL)
（3）意向锁
3.1表锁
表锁分为两类:
（1）表共享读锁，简称读锁
（2）表独占写锁，简称写锁
|----|----------------------|-------------------------|
| | 执行锁操作的会话 | 其他会话 |
| 读锁 | 只可读（只能DQL，不能DML、DDL） | 只可读（只能DQL，不能DML、DDL） |
| 写锁 | 可读可写（DQL、DML、DDL都可以） | 不可读不可写（DQL、DML、DDL都不可以） |
语法:
lock tables 表名 read或write;
#加锁
unlock tables;
#解锁，这条命令会解锁当前会话下的所有表锁
表锁是以会话为分界的，而不是以客户端为分界的，也不是以mysql用户为分界的。也就是说，在当前会话加了写锁，其他会话就无法读写（哪怕是同一客户端同一mysql用户）
3.2元数据锁
*元数据锁（MDL）是系统自动添加的，无需手动使用
*元数据锁是用来防止DML与DDL起冲突的
要明白元数据锁的作用，需要先回顾一下事务的4个隔离级别，其中mysql默认隔离级别Repeatable Read正是靠元数据锁来实现的
元数据锁也有共享读锁与独占写锁，二者相互排斥：
（1）当在一个事务中对某个表进行增删改查（DQL、DML）时，系统会自动给这个表加上共享读锁。其他事务可以对这个表进行增删改查，但不能修改表结构（DDL）
（2）当在一个事务中对某个表进行了修改表结构，即DDL操作（alter table ...），那么系统就会自动给这个表加上独占写锁，其他事务既不可对该表进行增删改查（DQL、DML），也不可修改表结构（DDL）
事务提交后，元数据锁会自动解开
3.3意向锁
对表进行DML操作时，系统会暂时给被操作的数据行加上行锁，如果这时还要给该表加上表锁，就会造成行锁与表锁的冲突（即DML自动添加的行锁与表锁的冲突），为了解决这个冲突的问题，就需要使用意向锁。
简单来说，意向锁是在进行DML操作时与行锁一起添加的，有了意向锁后，再要添加表锁，系统就会先判断表锁与所添加的意向锁是否兼容，如果兼容则可以加表锁，否则就不可。
意向锁有2种：
（1）意向共享锁（IS）
可由以下语句添加：
select... lock in share mode
IS与读锁（read）兼容，与写锁（write）互斥，也就是说，添加了IS后，可以对表加读锁，但不能加写锁
（2）意向排他锁（IX）
insert语句、update语句、delete语句会自动添加意向排他锁，select语句可由以下语句添加：
select...for update
IX与读锁、写锁都互斥
3.4三种表级锁总结
|-----|------------|---------------------|----------------------------------------|--------------------|
| || 是否是系统自动添加 | 对表的作用 | 一句话总结有啥用 |
| 元数据锁 || 是 | 我对这张表进行增删改查时，你也可以进行增删改查，但你不能更改表结构（DDL） | 解决DDL与DML的冲突 |
| 表锁 | 读锁（read） | 否 | 我不能对表增删改（DML），只能查（DQL）。 你也一样。 | 就锁表用的，你用你就加，不用就不加 |
| 表锁 | 写锁 （write） | 否 | 我可以对表增删改查。 你都不可以 | 就锁表用的，你用你就加，不用就不加 |
| 意向锁 | 意向共享锁（IS） | 否 | 表可以加read，不能加write | 解决DML自动添加的行锁与表锁的冲突 |
| 意向锁 | 意向排他锁（IX） | 执行增删改时是自动，执行查时需手动添加 | 表read、write都不能加 | 解决DML自动添加的行锁与表锁的冲突 |
4.行级锁
*行级锁：每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。
*应用在InnoDB存储引擎中。
*由于InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。
对于行级锁，主要分为以下三类:
（1）行锁(Record Lock)：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR事务隔离级别下都支持
（2）间隙锁(Gap Lock)：锁定索引记录间隙(不含该记录)，确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR事务隔离级别下支持。
（3）临键锁（Next-key Lock）：行锁+间隙锁。在RR事务隔离级别下支持。
4.1行锁
4.1.1共享锁与排他锁
InnoDB实现了以下2种行锁
（1）共享锁（S）:其他事务可以和当前事务一起读一行带有S的数据。共享锁之间可兼容，但与排他锁互斥。
（2）排他锁（X）:若某行数据被加上了排他锁，那么就只有当前事务能操作它，其他事务不能删改，也不能查。排他锁之间也是互斥的
4.1.2加锁以及查看锁
可以看到行锁的加锁情况与意向共享锁相同 ，也就说明二者会同时添加。
不要忘了意向共享锁是为了解决行锁与表锁的冲突才设置的，因此二者才会同时添加
*通过下图语句可以查看系统内的锁，其中IS是意向共享锁，
S,REC_NOT_GAP是共享锁，S,GAP是间隙锁，S是临键锁
4.1.3行锁自动升级为表锁的情况
InnoDB行锁是针对索引的锁，如果对没有索引 的字段加行锁，那么行锁就会自动升级为表锁
比如在事务A中修改a字段的数据（update），同时a字段没有索引，那么由于update操作自动给这行数据添加了排他锁，同时由于a字段没有索引，这个排他锁自动升级为表锁，这个表的每一行数据就都要收到排他锁的限制，事务B不能对这个表进行增删改查
4.2间隙锁与临键锁
RR隔离级别下不同索引在不同查询情况下的加锁类型：
|-------|------|---|---|---------|
| 非唯一索引 | 范围查询 ||| 临键锁 |
| 非唯一索引 | 等值查询 | 查询的值存在 || 临键锁+间隙锁 |
| 非唯一索引 | 等值查询 | 查询的值不存在 || 间隙锁 |
| 唯一索引 | 范围查询 ||| 行锁+间隙锁 |
| 唯一索引 | 等值查询 | 查询的值存在 || 行锁 |
| 唯一索引 | 等值查询 | 查询的值不存在 || 间隙锁 |
具体加锁过程可见如下连接：
https://blog.csdn.net/w15558056319/article/details/122861509?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522172309730016800182785516%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=172309730016800182785516&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-23-122861509-null-null.142^v100^pc_search_result_base5&utm_term=%E9%97%B4%E9%9A%99%E9%94%81&spm=1018.2226.3001.4187