温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

MySQL的全局锁和表级锁的具体使用方法

发布时间:2021-08-20 15:37:30 来源:亿速云 阅读:172 作者:chen 栏目:开发技术

这篇文章主要介绍“MySQL的全局锁和表级锁的具体使用方法”,在日常操作中,相信很多人在MySQL的全局锁和表级锁的具体使用方法问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”MySQL的全局锁和表级锁的具体使用方法”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

目录
  • 前言

  • 全局锁

  • 表级锁

    • 表锁

    • 元数据锁(Metadata Locking,简称:MDL锁)

  • 总结

    前言

    在真实的企业开发环境中使用MySQL,MySQL肯定不会只有我一个人使用,而是一个团队显式的使用MySQL,或者是业务隐式的使用MySQL,那么多个用户或者客户端连接使用的时候,我们应该考虑一个问题:如果保证数据并发访问的一致性呢?这一篇我就来聊聊MySQL的锁,不涉及MySQL的事务隔离级别。

    全局锁

    MySQL的全局锁会关闭所有打开的表,并使全部的表处于只读状态,它们的命令为:

    # 全局锁,简称FTWRL
    FLUSH TABLES WITH READ LOCK;
    
    # 解锁命令
    UNLOCK TABLES;

    对FTWRL进行实验:(以下的所有实验都是在MySQL8.0.22完成的)

    session1session2
    FLUSH TABLES WITH READ LOCK;
    select * from test limit 1;
    (正常返回结果)


    select * from test limit 1;
    (正常返回结果)
    insert into test(a,b,c) values(6,6,6);
    (报错)


    insert into test(a,b,c) values(8,8,8);# sql1
    (阻塞)
    UNLOCK TABLES;

    insert into test(a,b,c) values(8,8,8);# sql1
    (session1解锁后,sql1立马执行成功)

    从以上实验可以得出:当执行FTWRL后,所有的表变成了只读状态,其他更新的操作将会被阻塞。

    全局锁的主要作用就是做全库逻辑备份,也就是把数据库的每个表都select出来存成文本。

    当备份过程中,整个数据库处于只读状态,风险也是及其的大。如果是在主库备份,将会导致所有的业务表都不能修改数据;如果是在从库备份,这个时候从库不能执行主库传过来的binlog,会导致主从延迟。

    好在InnoDB存储引擎支持事务,mysqldump有一个参数single-transaction,可以在事务中创建一致性快照,然后进行所有表备份。在有这个参数下,备份期间可以进行数据修改,所以正常开发中建议使用InnoDB存储引擎。

    表级锁

    表级锁分为两种,一种是表锁,另一种是元数据锁。

    表锁

    表锁分为表读锁和表写锁,在MySQL的命令是:

    # 表读锁
    lock tables test read;
    
    # 表写锁
    lock tables test write;

    接下来通过实验看下表读锁和表写锁有什么区别吧

    表读锁

    session1session2
    lock tables test read;
    select * from test limit1;
    (正常返回结果)


    select * from test limit 1;
    (正常返回结果)
    insert into test(a,b,c) values(6,6,6);
    (报错)


    insert into test(a,b,c) values(8,8,8); # sql1
    (阻塞)
    unlock tables;

    insert into test(a,b,c) values(8,8,8); # sql1
    (session1解锁后,sql1立马写入成功)

    在session1会话加上了表读锁,这个时候session1和session2都可以正常的读数据,但是session1写数据会报错,session2写数据会被阻塞,等到session1解锁了,session2的写数据才能执行成功。

    从这个实验可以得出:表加上了表读锁之后,本线程和其他线程都可以读数据,本线程写数据会报错,其他线程写数据会阻塞。

    表写锁

    session1session2
    lock tables test write;
    select * from test limi1;
    (正常返回结果)


    select * from test limit 1; # sql1
    (阻塞)
    unlock tables;

    select * from test limit; # sql1
    (session1解锁后,sql1立马返回结果)
    lock tables test write;
    insert into test(a,b,c) values(6,6,6);
    (插入成功)


    insert into test(a,b,c) values(8,8,8);# sql 2
    (阻塞)
    unlock tables;

    insert into test(a,b,c) values(8,8,8);# sql2
    (session1解锁后,sql2立马执行成功)

    从以上实验可以得出:表加上了表写锁之后,本线程可以进行读写操作,其他线程的读写操作都会被阻塞。

    元数据锁(Metadata Locking,简称:MDL锁)

    在MySQL中,数据库的DDL不属于事务范畴,如果你在session1中select一行数据,这个时候session2给这张表新增了一列xxx,这个时候可能会出现事务特性被破坏、binlog顺序错乱等bug(MySQL官网上有公布出类似的bug,感兴趣可以自行去了解)。

    为了解决以上的问题,从MySQL5.5.3引入了元数据锁,MDL锁不需要显式使用,MySQL会默认加上,它的作用就是保证数据库读写正确性。以下全部用MDL表示元数据锁。

    当你对一张表进行增删查改的时候会默认加上MDL读锁;当你对一张表进行表结构更改的时候会默认加上MDL写锁。

    session1session2session3session4
    begin;


    select * from test lmi1;
    (正常返回结果)




    select * from test limit 1;
    (正常返回结果)




    alter table test add d int;
    (阻塞)




    select * from test limit 1;
    (阻塞)

    一开始session1会话查询test的时候,获取到了MDL读锁,可以正常查询到数据。然后session2会话查询数据也会获取MDL读锁,不冲突,也可以正常查询到数据返回。

    但是到了session3会话的时候,需要获取MDL写锁,这个时候因为session1的MDL读锁没有释放,所以会阻塞。后面session4也需要MDL读锁,但是因为session3被阻塞了,所以session4也会被阻塞。

    假如这是一张线上业务表,这种场景将会使后面的任何操作都失效,表现出来就是这张表变得无法写和读。如果客户端配置了MySQL重试机制的话,会在超时的时候重新建立一个session会话重新请求,然后MySQL就会因为线程不停新增而崩溃。

    从上面的例子可以知道MDL锁是在语句执行的时候默认加上的,但是语句执行完是不会释放的,只有等整个事务提交了才会释放MDL锁。

    所以对于我们开发者来说,在工作中应该尽量避免慢查询、尽量保证事务及时提交、避免大事务等,对于DBA来说,也应该尽量避免在业务高峰期执行DDL操作。

    总结

    • 全局锁会让所有的表变成只读状态,所有更新操作都会被阻塞

    • 表读锁是本线程和其他线程都可以读,本线程写会报错,其他线程写会阻塞

    • 表写锁是本线程可以读写,其他线程读写都会阻塞

    • 引入MDL锁解决事务和DDL同时执行引发的bug

    到此,关于“MySQL的全局锁和表级锁的具体使用方法”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!

    向AI问一下细节

    免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

    AI