当前位置 : 主页 > 编程语言 > java >

mysql学习笔记(六)全局锁和表级锁

来源:互联网 收集:自由互联 发布时间:2022-06-23
mysql的锁分为全局锁、表级锁、行锁。 这里我们只分析全局锁和表级锁。 全局锁 就是对整个库进行加锁,整个库会处于只读状态,之后其他线程的以下语句会被阻塞:数据更新语句(

mysql的锁分为全局锁、表级锁、行锁。

这里我们只分析全局锁和表级锁。

全局锁

就是对整个库进行加锁,整个库会处于只读状态,之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。

语法:Flush tables with read lock;     即:FTWRL

释放锁:unlock tables;

适用场景:全库的逻辑备份

全局锁的影响:

  • 主库上操作,业务基本停摆,无法进行任何更新操作
  • 从库上操作,备份期间不能更新主库同步过来的binlog,导致主动不一致
  • 如果不加锁,导致备份数据前后不一致,无法保证数据的一致性
  •  

    mysqldump (官方自带逻辑备份工具)

    当 mysqldump 使用参数 –single-transaction 的时候,导数据之前就会启动一个事务,来确保拿到一致性视图。而由于 MVCC 的支持,这个过程中数据是可以正常更新的。

    注:MVCC ,数据库的多版本并发控制

    –single-transaction  使用前提:库中所有表都是支持事务引擎的

     

    FTWRL 和 set global readonly=true 的异同点?

    共同点: 都是将整个库设置为只读状态

    不同点:

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

    表级锁

    表极锁分为表锁和元数据锁(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 都不允许,自然也不能访问其他表。

     

    元数据锁(meta data lock,MDL)

    语法:不需要显式使用,在访问一个表的时候会自动加上。

    释放锁:事务中的 MDL 锁,在语句执行开始时申请,但是语句结束后并不会马上释放,而会等到整个事务提交后再释放。

    作用:保证读写的正确性,防止DDL和DML并发冲突

    举个例子:如果一个查询正在遍历一个表中的数据,而执行期间另一个线程对这个表结构做变更,删了一列,那么查询线程拿到的结果跟表结构对不上,肯定是不行的。

    因此,在 MySQL 5.5 版本中引入了 MDL,

    当对一个表做增删改查操作(DML)的时候,加 MDL 读锁;

    当要对表做结构变更操作(DDL)的时候,加 MDL 写锁。

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

    现实场景:

    mysql学习笔记(六)全局锁和表级锁_mysql

     

     

     我们可以看到 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 ...

     

    参考地址:
    ​​​https://time.geekbang.org/column/article/69862​​

    上一篇:docker下php安装imagick扩展
    下一篇:没有了
    网友评论