• MySQL 全局锁、表锁和行锁


    最近在极客时间看丁奇大佬的《MySQL45讲》,真心觉得讲的不错,把其中获得的一些MySQL方向的经验整理整理分享给大家,有兴趣同学可以购买相关课程进行学习。

    今天分享的内容是MySQL的全局锁、表锁和行锁。

    1、全局锁

    全局锁,是指对整个MySQL数据库加锁,对应的命令是flush tables with read lock;(以下简称FTWRL)

    当你需要让整个库处于只读模式的时候,可以使用这个语法,它的应用场景,一般是在全库逻辑备份的时候。我们知道MySQL自带的mysqldump逻辑备份工具可以使用--single-transaction参数来进行备份,因为Innodb存储引擎支持事务和MVCC的原理,所以该备份方法没有问题。但是,在你使用MyISAM等存储引擎时,该语句可以保证在备份期间的数据一致性。而

    --single-transaction方法只适用于所有的表使用事务引擎的库;

    2、表级锁

    MySQL里面表级别的锁有两种,一种是表锁,一种是元数据锁(MDL)

    表锁的加锁方式为lock tables xxx read,解锁方式是unlock tables xxx,需要注意的是:

    lock tables语法除了会限制别的线程的读写外,也限定了本线程接下来的操作对象。举个例子, 如果在某个线程A中执行lock tables t1 read, t2 write; 这个语句,则其他线程写t1、读写t2的语句都会被阻塞。当前线程也不能对表t1做写的操作

    MDL元数据锁是指在对一个表做增删改查的时候,MySQL会对该表加MDL读锁,防止另外一个线程对该表做变更操作,当对一个表做表结构变更的时候,会对该表加MDL写锁。MDL锁不需要显式使用,在访问一个表的时候会被自动加上

    MDL锁可能会造成MySQL宕掉!!!举例如下:

    当我们开启多个事务的时候,假设事务的内容都是一个begin+简单的select语句(加MDL读锁),当其中一个事务没有及时提交,此时如果有一个alter table的操作(导致MDL读锁升级为MDL写锁),会导致后续的select语句,都被阻塞,即使这个表的记录数很少,在事务不及时提交的情况下,也会导致整个库不可读。如果此时应用方面有重连机制,则会导致连接数被快速打满,这往往是灾难性的。此场景中,即使使用pt工具进行表结构变更,也无法解决问题。

    还需要注意,如果事务中没有begin的话,这样select执行完成以后,MDL就自动释放了,则不会造成MDL锁等待。

    3、行锁

    行锁里面比较重要的一个概念:两阶段锁,它是指:

    在InnoDB事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放,而是要等到事务结束时(commit动作完成之后)才释放。

    从这个两阶段锁机制中我们不难发现一个好的习惯:

    如果你的事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放

    行锁的产生,可以大大降低死锁的概率(是降低,不是杜绝),但是这种热点行的频繁更新,往往会导致MySQL的性能问题(因为死锁检测会消耗大量的CPU资源)。如何解决热点行的频繁更新带来的性能问题?

    1、关闭死锁检测参数innodb_deadlock_detect,这种操作,往往不是最优的,因为可能出现大量因为死锁带来的超时问题。

    2、控制并发,核心思路就是相同行的更新,在进入引擎之前进入队列排队。

    最后,死锁的两个关键参数:

    innodb_deadlock_detect:死锁检测参数,默认为on,发现死锁后,主动回滚死锁链条中的某一个事务,让其他事务得以继续执行

    innodb_lock_wait_timeout:死锁等待的超时时间,默认为50s,意味着如果不开启死锁检测,则在发生死锁之后,会等待50s,直到超时。

    ----------------------------

    思考题:

    备份一般都会在备库上执行,你在用–single-transaction方法做逻辑备份的过程中,如果主库上的一个小表做了一个DDL,比如给一个表上加了一列。这时候,从备库上会看到什么现象呢?

    参考答案:

    本质上,MySQLdump+transaction参数进行备份的过程中,我们可以认为它做了如下的动作:

    T0:begin;

    T1:savepoint sp;

    T2: show create t1;

    T3:select * from t1;(执行一段时间)

    T4:rollback to sp;

    T1时刻mysqldump设置一个保存点,然后拿到t1表的表结构(T2)和表数据(T3),最后,再回到保存点sp(T4),整个过程中,如果:

    在T2时间之前,在表上增加了一列,从库上没有影响。

    在T2和T3之间,在表上增加了一列,则报错 Table definition has changed, please retry transaction

    MySQL备份中止

    在T3期间到达,则因为此时正在备份,mysqldump占着t1的MDL读锁,binlog被阻塞,现象:主从延迟,直到T4执行完成

    在T3和T4之间到达,则没有影响,因为mysqldump已经释放了MDL读锁

    赞赏码

    非学,无以致疑;非问,无以广识

  • 相关阅读:
    C# 简单的 Job 作业~
    反射反射,程序员的快乐+反射案例:打印和Excel导出
    设计模式:装饰模式(decorate)
    UML类图应该怎么看?
    WebApi 异步请求(HttpClient)
    设计模式:单一职责原则,开放封闭原则,依赖倒转原则,理氏代换原则
    【BOOM】一款有趣的Javascript动画效果
    【深入浅出jQuery】源码浅析2--奇技淫巧
    【深入浅出jQuery】源码浅析--整体架构
    【CSS进阶】原生JS getComputedStyle等方法解析
  • 原文地址:https://www.cnblogs.com/lxwphp/p/15452681.html
Copyright © 2020-2023  润新知