美文网首页
浅谈MySQL数据库锁

浅谈MySQL数据库锁

作者: 程序员小韩 | 来源:发表于2022-03-09 13:06 被阅读0次

      

    作为一个程序员,每日必打交道的就是数据库,而现在市场对于MySQL数据库的要求就是必会。(我自己观察的啊,莫要认真……(#^.^#)  ),那么今天我们就简单聊一聊MySQL数据库锁。

    一、什么是锁

            数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性。

        加锁是实现数据库并发控制的一个非常重要的技术。

        当事务在对某个数据对象进行操作前,先向系统发出请求,对其加锁。加锁后事务就对该数据对象有了一定的控制,在该事务释放锁之前,其他的事务不能对此数据对象进行更新操作。

    二、数据库锁分类

    • 按照锁的颗粒度  可分为:行级锁、页级锁、表级锁

    • 按照锁的级别 可分为:共享锁、排它锁

    • 按照锁的方式 可分为:自动锁、显示锁

    • 按照锁的使用方式 可分为:乐观锁、悲观锁

        

        简单理解 :

    • 共享锁等价于读锁(Read Lock)

    • 排它锁等价于写锁(Write Lock)

        

    • 悲观锁:指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。

    • 乐观锁: 采用了一种“乐观”的方式,它只有在数据 commit 时,才会进行排它性的检查。不过乐观锁也不是没有缺点,乐观锁适用于写操作比较少的情况,即冲突很少发生的情况。如果经常发生冲突的话,使用乐观锁反而会影响性能,降低系统的吞吐量。

        行级锁、页级锁、表级锁

    • 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。

    • 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。

    • 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。

    三、MySQL 存储引擎使用的锁机制

    • MyISAM 存储引擎采用的是表级锁(table-level-locking),

    • InnoDB 存储引擎既支持行级锁(row-level-locking)也支持表级锁,但是默认的情况下采用的是行级锁。

    • BDB 采用的是页级锁(page-level-locking),同时 BDB 也支持表级锁   (我们不常使用到的一种存储引擎,其他的不说了,我也不知道 emo (ಥ﹏ಥ)!)

    3.1 MyISAM 存储引擎的锁机

             当我们对一张表进行查询操作(select)时,MyISAM 存储引擎会对这张表自动加上一个读锁;

            当对这张表进行 插入、修改、删除(insert、update、delete)时,MyISAM 存储引擎会对这张表自动加上一个写锁。

    eg:

    当我们对一张表,进行查询操作 s1,但还没得到查询结果时,这是新增一个查询操作s2时,s1和s2操作都不会被阻塞,s1和s2都可查出结果。由此能粗略的得出共享锁对读操作是兼容的;

    当我们对一张表,进行查询操作s1,但还没有得到查询结果时,同时进行更新操作u1,此时u1会被阻塞,需要等待s1完成后,在进行u1。粗略的得出排它锁对读写操作是不兼容的

    上述说的都是自动锁,由MyISAM主动加锁。手动锁如下示例:

    lock tables drug read,prescription read;select sum(drug_pricel) from drug ;select sum(prescription_pricel) from prescription ;unlock tables;

    锁的颗粒度是在表上。

    3.2、 InnoDB 存储引擎的锁机制

    InnoDB 存储引擎支持事务,并且在默认的情况下是自动提交事务的,它的机制是为同一批事务提交之前加锁,然后 commit 后再一起释放。

    关于事务自动提交,可通过设置autocommit =0关闭事务的自动提交。

    set autocommit = 0;

    InnoDB 存储引擎默认是 行级锁

      eg:

          当我们对一张表 中的id=1的数据进行修改操作 u1时,在事务没有commit时,此时对id=2的数据也进行修改操作u2,此时可以发现 u2是可以操作成功的,证明u2并没有受到u1锁的影响而发生阻塞;

            但是如果我们对id=1的数据在进行修改操作u2,此时会发现u2 会被阻塞,需要等待u1执行结束后在执行u2。

            这便粗略的验证了 InnoDB 默认加锁的粒度是行级锁

    不过,有个前提条件,那就是 :

    查询的字段上必须有索引,如果没有索引 InnoDB 还是会对整个表加锁

    当我们的 sql 语句操作字段没有走索引时,InnoDB 还是会在整个表这个粒度上加锁。所以说,InnoDB 既支持行级锁,也支持表级锁。

    四、死锁

          我们平时工作中使用的比较多的就是InnoDB ,默认用的也是行级锁,

    但是行级锁一定比表级锁好么?

            其实不然,行级锁的并发度虽然比表级锁要高,但是表级锁的开销比较小,加锁的速度很快;行级锁的开销则比较大,并且加锁的速度慢,最重要的是  

    行级锁可能会出现死锁现象

    死锁  :是指两个或两个以上的进程或线程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。

    形成死锁必须满足四个必要条件:

    • 互斥条件

    • 请求与保持条件

    • 不剥夺条件

    • 环路等待条件

    互斥条件:是指进程对所分配到的资源进行排它性使用。说白了就是在一段时间内,某个资源每次只能被一个进程所占用。

    请求与保持条件:是指进程已经保持至少一个资源,但又提出了新的资源请求,而该资源已被其它进程占有,此时请求进程阻塞,但又对自己已获得的其它资源保持不放,说人话就是“有了碗里的饼,还嚷嚷着要吃锅里的汤”。

    不剥夺条件:是指进程已获得的资源在未使用完之前,不能被剥夺,只能由自己释放,说人话就是“自己拿到了就不给别人用,自己用完了才给别人”。

    环路等待条件:是指当发生死锁时,必然存在着一个资源的请求环形链,若干进程在这个环形链中循环等待。

    避免死锁有以下几种常见的策略:

    • 设置获得锁的超时时间

    • 避免长事务

    • 避免事务中的用户交互

    • 降低隔离级别

    好了,关于数据库锁就白话到这里吧。

    …………………………………分割线……………………………

    不积跬步,无以至千里;不积小流,无以成江海。

    关注我,每天分享一些小知识点。分享自己的小心得,包含但不限于初、中、高级面试题呦!!!

    我都墨迹这么半天了 ,你不点关注,不点赞,不收藏,还不转发,你想干啥!!!!

    相关文章

      网友评论

          本文标题:浅谈MySQL数据库锁

          本文链接:https://www.haomeiwen.com/subject/apetdrtx.html