mysql中的锁都有哪些

MySQL 中有哪些锁？

数据库中锁的设计初衷处理并发问题，作为多用户共享资源，当出现并发访问的时候，数据库需要合理控制资源访问规则。锁就是实现这些访问规则中的重要数据。

锁的分类

根据加锁范围，MySQL 里面的锁可以分成 全局锁 、 表级锁 、 行锁 三类。

全局锁

全局锁，就是对整个数据库实例加锁，MySQL 提供了一个加全局读锁的方法，命令是:

Flush tables with read lock (FTWRL)

当需要整个库只读状态的时候，可以使用这个命令，之后其他线程的：数据更新语句（增删改），数据定义语句（建表，修改表结构）和更新事务的提交语句将会被阻塞。

全局锁的使用场景

全局锁的定型使用场景，做 全库逻辑备份 。也就是把整个库每个表都 Select 出来，然后存成文本。

如何整个库都只读，会有什么问题？ 如果你在主库上备份，那么在备份期间都不能执行更想，业务就基本上停摆。 如果在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog ,会导致从延迟。 既然要全库只读， 为什么不使用set global readonly=true的方式呢?

readonly 方式也可以让全库进入只读状态,但我还是会建议你用FTWRL方式， 主要有两个原因：

一是， 在有些系统中， readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大， 我不建议你使用。 二是， 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开， 那么MySQL会自动释放这个全局锁， 整个库回到可以正常更新的状态。而将整个库设置为readonly之后， 如果客户端发生异常， 则数据库就会一直保持readonly状态， 这样会导致整个库长时间处于不可写状态， 风险较高 表级别锁

MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lok, MDL）。表锁的语法是 ：

lock tables ... read/write

与 FTWRL 类似,可以使用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。需要注意的是，lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的 *** 作对象。

MDL 表级锁

MDL 不需要显示使用，在访问一个表的时候自动加上， MDL 保证读写的正确性，也就是说在查询数据时，不允许有其他线程对这个表结构做变更。

什么 *** 作会加 MDL 锁？

在MySQL 5.5版本中引入了MDL， 当对一个表做增删改查 *** 作的时候，加 MDL读锁 ；当要对表做结构变更 *** 作的时候，加 MDL写锁 。

读锁之间不互斥，因此可以有多个线程同时对一张表增删改查。 读写之间、写锁之间是互斥的，用来保证变更表结构 *** 作的安全性，如果有两个线程要同时给一个表加字段，其中一个要等另外一个执行完才能执行。 更改表结构要注意哪些？

给一个表加字段， 或者修改字段， 或者加索引， 需要扫描全表的数据。在对大表 *** 作的时候， 你肯定会特别小心， 以免对线上服务造成影响。而实际上， 即使是小表， *** 作不慎也会出问题，导致整个库的线程爆满。

举个例子

我们来看一下下面的 *** 作序列， 假设表t是一个小表。

image

session A先启动， 这时候会对表t加一个 MDL读锁 。由于session B需要的也是 MDL读锁 ， 因此可以正常执行。 session C会被blocked， 是因为session A的MDL读锁还没有释放， 而session C需要MDL写锁， 因此只能被阻塞，读写锁互斥。 如果只有session C自己被阻塞还没什么关系， 但是之后所有要在表t上新申请MDL读锁的请求也会被session C阻塞。前面我们说了，所有对表的增删改查 *** 作都需要先申请MDL读锁， 就都被锁住， 等于这个表现在完全不可读写了。

如果某个表上的查询语句频繁， 而且客户端有重试机制，也就是说超时后会再起一个新session 再请求的话， 这个 库的线程很快就会爆满 。事务中的MDL锁， 在语句执行开始时申请， 但是语句结束后并不会马上释放， 而会等到整个事务提交后再释放。

怎么解决这个 更改表结构问题

比较理想的机制是， 在alter table语句里面设定等待时间， 如果在这个指定的等待时间里面能够拿到MDL写锁最好， 拿不到也不要阻塞后面的业务语句， 先放弃。

ALTER TABLE tbl_name NOWAIT add column ... ALTER TABLE tbl_name WAIT N add column ...

修改方法

有两种方法可以对配置了 systemd 的程序进行资源隔离：1. 命令行修改：通过执行 systemctl set-property 命令实现，形式为 systemctl set-property name parameter=value；修改默认即时生效。2. 手工修改文件：直接编辑程序的 systemd unit file 文件，完成之后需手工执行 systemctl daemon-reload 更新配置，并重启服务 systemctl restart name.service。

systemd unit file 里支持的资源隔离配置项，如常见的：

CPUQuota=value

该参数表示服务可以获取的最大 CPU 时间，value 为百分数形式，高于 100% 表示可使用 1 核以上的 CPU。与 cgroup cpu 控制器 cpu.cfs_quota_us 配置项对应。

MemoryLimit=value

该参数表示服务可以使用的最大内存量，value 可以使用 K, M, G, T 等后缀表示值的大小。与 cgroup memory 控制器 memory.limit_in_bytes 配置项对应。

事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。

READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                    

Gap locking 仅用于外键约束检查和重复键检查。

REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。

SERIALIZABLE           序列化在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

---