mysql的锁分为全局锁、表级锁、行锁。
就是对整个库进行加锁,整个库会处于只读状态,之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。
语法:Flush tables with read lock; 即:FTWRL
释放锁:unlock tables;
适用场景:全库的逻辑备份
全局锁的影响:
当 mysqldump 使用参数 –single-transaction 的时候,导数据之前就会启动一个事务,来确保拿到一致性视图。而由于 MVCC 的支持,这个过程中数据是可以正常更新的。
注:MVCC ,数据库的多版本并发控制,可参见: https://www.cnblogs.com/wanghaokun/p/16024354.html
–single-transaction 使用前提:库中所有表都是支持事务引擎的
共同点: 都是将整个库设置为只读状态
不同点:
表极锁分为表锁和元数据锁(meta data lock,MDL)。
语法:lock tables ... read/write。
释放锁:可用unlock tables 主动释放锁,也可在客户端断开时自动释放。
注意:lock tables 语法除了会限制别的线程读写外,也限定了本线程接下来的操作对象。
举个例子:
如果在某个线程 A 中执行 lock tables t1 read, t2 write; 这个语句,则其他线程写 t1、读写 t2 的语句都会被阻塞。
同时,线程 A 在执行 unlock tables 之前,也只能执行读 t1、读写 t2 的操作。连写 t1 都不允许,自然也不能访问其他表。
语法:不需要显式使用,在访问一个表的时候会自动加上。
释放锁:事务中的 MDL 锁,在语句执行开始时申请,但是语句结束后并不会马上释放,而会等到整个事务提交后再释放。
作用:保证读写的正确性,防止DDL和DML并发冲突
举个例子:如果一个查询正在遍历一个表中的数据,而执行期间另一个线程对这个表结构做变更,删了一列,那么查询线程拿到的结果跟表结构对不上,肯定是不行的。
因此,在 MySQL 5.5 版本中引入了 MDL,
当对一个表做增删改查操作的时候,加 MDL 读锁;
当要对表做结构变更操作的时候,加 MDL 写锁。
因此,如果有两个线程要同时给一个表加字段,其中一个要等另一个执行完才能开始执行。
现实场景:
我们可以看到 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 锁。在 MySQL 的 information_schema 库的 innodb_trx 表中,你可以查到当前执行中的事务。如果你要做 DDL 变更的表刚好有长事务在执行,要考虑先暂停 DDL,或者 kill 掉这个长事务。
在 alter table 语句里面设定等待时间,如果在这个指定的等待时间里面能够拿到 MDL 写锁最好,拿不到也不要阻塞后面的业务语句,先放弃。之后开发人员或者 DBA 再通过重试命令重复这个过程。
ALTER TABLE tbl_name NOWAIT add column ... ALTER TABLE tbl_name WAIT N add column ...