码迷,mamicode.com
首页 > 数据库 > 详细

MySQL的事务与锁 转

时间:2020-07-07 09:30:09      阅读:64      评论:0      收藏:0      [点我收藏+]

标签:starting   手工   mod   personal   https   red   pre   语句   serial   

资料来源:

青山老师的mysql课程

丁奇老师的《MySQL45讲》

一、文章结构和思路

1.整体文章结构

技术图片

2、大概思路

  • 介绍数据库的特性;
  • 数据库标准所制定的隔离级别和解决对应的一致性问题;
  • 数据库的锁:事务的实现依赖于数据库锁的;
  • 在了解基本的锁结构之后,再了解他们之间的关系;
  • 文章穿插了数据库的一些实际的的操作,便于理解;

3、从问题中出发

  1. 什么是脏读、不可重复读、幻读,不可重复读和幻读有什么区别?
  2. 是么数据库的事务,ACID在数据库层面都是怎么实现的?
  3. 哪些方式会导致死锁?

答案

  1. 不可重复读是修改或者删除,幻读是插入。(看到网上的描述,好多是错误的,这个是sql92标准里的说明)

技术图片

技术图片

  1. 看文章内容
  2. 不要在加上了读锁以后去写数据,不然的话可能会出现死锁的情况。

小知识点

在 InnoDB 中,MVCC 和锁是协同使用的,这两种方案并不是互斥的。

二、数据库事务

按照惯例,还是把相关概念解释一下

什么是事务?

维基百科:事务是数据库管理系统(DBMS)执行过程中的一个逻辑单位,由一个有限的数据库操作序列构成;

Ⅰ、事务四个特性(ACID)

  • 原子性:对数据库的一系列的操作,要么都是成功,要么都是失败,不可能出现部分成功或者部分失败的情况;

    原子性,在 InnoDB 里面是通过 undo log 来实现的,它记录了数据修改之前的值(逻辑日志),一旦发生异常,就可以用 undo log 来实现回滚操作。

  • 一致性:是数据库的完整性约束没有被破坏,事务执行的前后都是合法的数据状态。

  • 隔离性:在数据库里面会有很多的 事务同时去操作我们的同一张表或者同一行数据,必然会产生一些并发或者干扰的操作, 那么我们对隔离性的定义,就是这些很多个的事务,对表或者行的并发操作,应该是透明的,互相不干扰的。通过这种方式,我们最终也是保证业务数据的一致性。

  • 持久性:我们对数据库的任意的操作,增删改,只要事务提交成功,那么结果就是永久性的,不可能因为我们系统宕机或者重启了数据库的服务器,它又恢复到原来的状态了;

    持久性是通过 redo log 和 double write 双写缓冲来实现的。

MySQL中,InnoDB和NDB支持事务

spring的事务依赖于数据库实现,通过切面或注解实现不同的事务:

<tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> 
    <tx:method name="save*" rollback-for="Throwable" /> 
    <tx:method name="add*" rollback-for="Throwable" /> 
    <tx:method name="send*" rollback-for="Throwable" /> 
    <tx:method name="insert*" rollback-for="Throwable" /> 
</tx:attributes> </tx:advice>

Ⅱ、数据事务的参数配置

开启一个事务

MySQL 的事务启动方式有以下几种:

1、显式启动事务语句, begin 或 start transaction。配套的提交语句是 commit,回滚语句是 rollback。

2、set autocommit=0,这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句,这个事务就启动了,而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句,或者断开连接。

-- 查看数据库版本
select version(); 
-- 查看数据库引擎
show variables like ‘%engine%‘;
-- 查看事务的隔离级别
show global variables like "tx_isolation";
-- 查看数据的事务提交方式
show variables like ‘autocommit‘;
设置数据库事务的提交方式
-- 设置自动提交->回话级别
set global autocommit=0;  
-- 修改配置文件
init_connect=‘SET autocommit=off‘;

Ⅲ、事务的隔离级别问题

1、事务的隔离级别

读未提交:一个事务还没提交时,它做的变更就能被别的事务看到。

读提交:一个事务提交之后,它做的变更才会被其他事务看到。

可重复读:一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下,未提交变更对其他事务也是不可见的。

串行化:顾名思义是对于同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行。

2、事务的读一直性问题

脏读:A事务读取B事务尚未提交的数据并在此基础上操作,而B事务执行回滚,那么A读取到的数据就是脏数据

不可重复读:事务A重新读取前面读取过的数据,发现该数据已经被另一个已提交的事务B修改过了。

幻读:事务A重新执行一个查询,返回一系列符合查询条件的行,发现其中插入了被事务B提交的行。

3、SQL92 标准

SQL92标准描述了隔离级别与数据读一致性问题

技术图片

? P1 P2 P3 就是 代表事务并发的 3 个问题;

4、MySQL的隔离级别

? 图片中的蓝色文字,在了解了InnoDB的锁之后,就会明白
技术图片

5、数据读一致性方案

1、LBCC

? 我既然要保证前后两次读取数据一致,那么我读取数据的时候,锁定我要 操作的数据,不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制 Lock Based Concurrency Control(LBCC)。 如果仅仅是基于锁来实现事务隔离,一个事务读取的时候不允许其他时候修改,那 就意味着不支持并发的读写操作,而我们的大多数应用都是读多写少的,这样会极大地 影响操作数据的效率。

2、MVCC

? 如果要让一个事务前后两次读取的数据保持一致, 那么我们可以在修改数据的时候给它建立一个备份或者叫快照,后面再来读取这个快照 就行了。这种方案我们叫做多版本的并发控制 Multi Version Concurrency Control (MVCC)。

? MVCC 的核心思想是: 我可以查到在我这个事务开始之前已经存在的数据,即使它

在后面被修改或者删除了。在我这个事务之后新增的数据,我是查不到的。

三、MySQL的InnoDB的锁类型

1、锁的分类

官网八种锁,找到一偏解释的文章

分别对应的是:

  • 共享锁和独占锁
  • 意向锁
  • 记录锁
  • 间隙锁
  • 临键锁
  • 插入意向锁
  • AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁
  • 谓词锁

2、锁的粒度

行锁、表锁:表锁,顾名思义,是锁住一张表;行锁就是锁住表里面的一行数据。

锁分类行锁表锁
锁定粒度 小于表锁  
冲突概率   表锁的冲突概率更大,所以并发性能更低

3、共享锁(读锁)

共享锁:也叫读锁,一个事务获取了一行数据的读锁之后,其他的事务可以再次获取查询数据,需要注意的是:不要在加上了读锁以后去写数据,不然的话可能会出现死锁的情况。

可以用 select …… lock in share mode;的方式手工加上一把读锁。

释放锁有两种方式,只要事务结束,锁就会自动释放事务,包括提交事务和结束事务。

4、排它锁(写锁)

第二个行级别的锁叫做 Exclusive Locks(排它锁),它是用来操作数据的,所以又叫做写锁。只要一个事务获取了一行数据的排它锁,其他的事务就不能再获取这一行数据的共享锁和排它锁。

1、排它锁的加锁方式有两种,第一种是自动加排他锁。我们在操作数据的时候,包括增删改,都会默认加上一个排它锁。

2、还有一种是手工加锁,我们用一个 FOR UPDATE 给一行数据加上一个排它锁,这个无论是在我们的代码里面还是操作数据的工具里面,都比较常用。

5、意向锁

当我们给一行数据加上共享锁之前,数据库会自动在这张表上面加一个意向共享锁。

当我们给一行数据加上排他锁之前,数据库会自动在这张表上面加一个意向排他锁。

? 1、如果一张表上面至少有一个意向共享锁,说明有其他的事务给其中的某些数据行加上了共享锁。

? 2、如果一张表上面至少有一个意向排他锁,说明有其他的事务给其中的某些数据行加上了排他锁。

当我们需要使用表锁的时候(改变表结构),需要去判断是否数据加了行锁,如果是最后一行,数据量大的情况下,效率就特别低,而意向锁解决了这个问题;

到这里我们要思考两个问题:

1.锁的作用是什么?

它跟 Java 里面的锁是一样的, 是为了解决资源竞争的问题,Java 里面的资源是对象,数据库的资源就是数据表或者数 据行。所以锁是用来解决事务对数据的并发访问的问题的。

2.那么,锁到底锁住了什么呢?

当一个事务锁住了一行数据的时候,其他的事务不能操作这一行数据,那它到底是锁住了这一行数据,还是锁住了这一个字段,还是锁住了别的什么东西呢?

6、锁锁住的是什么?

锁锁住的是主键索引:是不是有很多问题?

技术图片

1、为什么表里面没有索引的时候,锁住一行数据会导致锁表? 或者说,如果锁住的是索引,一张表没有索引怎么办? 所以,一张表有没有可能没有索引?

1)如果我们定义了主键(PRIMARY KEY),那么 InnoDB 会选择主键作为聚集索引。

2)如果没有显式定义主键,则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引。

3)如果也没有这样的唯一索引,则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引,它会随着行记录的写入而主键递增。

所以,为什么锁表,是因为查询没有使用索引,会进行全表扫描,然后把每一个隐藏的聚集索引都锁住了。

2、为什么通过唯一索引给数据行加锁,主键索引也会被锁住?

我们通过辅助索引锁定一行数据的时候,它跟我们检索数据的步骤是一样的,会通过主键值找到主键索引,然锁住主键索引

四、锁算法

  • 假设表里有1、4、7、9为主键的四条数据,三中锁的结构如下

技术图片

  • 数据库里面存在的主键值,我们把它叫做 Record,记录,那么这里我们就有 4个 Record。

  • 根据主键,这些存在的 Record 隔开的数据不存在的区间,我们把它叫做 Gap,间隙,它是一个左开右开的区间。

  • 间隙(Gap)连同它左边的记录(Record),我们把它叫做临键的区间,它是一个左开右闭的区间。

  • 若果主键为非整数类型,通过用ASCII码来排序。

Ⅰ、记录锁

第一种情况,当我们对于唯一性的索引(包括唯一索引和主键索引)使用等值查询,精准匹配到一条记录的时候,这个时候使用的就是记录锁。

? where id = 1 4 7 10

Ⅱ、间隙锁

第二种情况,当我们查询的记录不存在,没有命中任何一个 record,无论是用等值
查询还是范围查询的时候,它使用的都是间隙锁。

where id >4 and id <7,where id = 6。

Gap Lock 只在 RR 中存在。如果要关闭间隙锁,就是把事务隔离级别设置成 RC,并且把 innodb_locks_unsafe_for_binlog 设置为 ON。这种情况下除了外键约束和唯一性检查会加间隙锁,其他情况都不会用间隙锁。

Ⅲ 、临键锁

第三种情况,当我们使用了范围查询,不仅仅命中了 Record 记录,还包含了 Gap间隙,在这种情况下我们使用的就是临键锁,它是 MySQL 里面默认的行锁算法,相当于
记录锁加上间隙锁。

唯一性索引,等值查询匹配到一条记录的时候,退化成记录锁。

没有匹配到任何记录的时候,退化成间隙锁。

比如我们使用>5 <9, 它包含了记录不存在的区间,也包含了一个 Record 7。

为什么要锁住下一个左开右闭的区间?——就是为了解决幻读的问题

Ⅳ 、小结

再次回顾一下这张表

技术图片

  1. Read Uncommited:RU 隔离级别:不加锁

  2. Serializable:Serializable 所有的 select 语句都会被隐式的转化为 select ... in share mode,会和update、delete 互斥。

  3. Repeatable Read

    • RR 隔离级别下,普通的 select 使用快照读(snapshot read),底层使用 MVCC 来实现
    • 加锁的 select(select ... in share mode / select ... for update)以及更新操作update, delete 等语句使用当前读(current read),底层使用记录锁、或者间隙锁、临键锁。
  4. Read Commited

    • RC 隔离级别下,普通的 select 都是快照读,使用 MVCC 实现。

    • 加锁的 select 都使用记录锁,因为没有 Gap Lock

    • 除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会使用间隙锁封锁区间;所以 RC 会出现幻读的问题。

Ⅴ 、事务隔离级别怎么选?

RU 和 Serializable 肯定不能用。为什么有些公司要用 RC,或者说网上有些文章推荐有 RC?

RC 和 RR 主要有几个区别:

? 1、 RR 的间隙锁会导致锁定范围的扩大。

? 2、 条件列未使用到索引,RR 锁表,RC 锁行。

? 3、 RC 的“半一致性”(semi-consistent)读可以增加 update 操作的并发性。

? 在 RC 中,一个 update 语句,如果读到一行已经加锁的记录,此时 InnoDB 返回记录最近提交的版本,由 MySQL 上层判断此版本是否满足 update 的 where 条件。若满足(需要更新),则 MySQL 会重新发起一次读操作,此时会读取行的最新版本(并加锁)。

实际上,如果能够正确地使用锁(避免不使用索引去枷锁),只锁定需要的数据,用默认的 RR 级别就可以了。

? 在我们使用锁的时候,有一个问题是需要注意和避免的,我们知道,排它锁有互斥的特性。一个事务或者说一个线程持有锁的时候,会阻止其他的线程获取锁,这个时候会造成阻塞等待,如果循环等待,会有可能造成死锁。

Ⅵ 、死锁
  • 锁什么时候释放:事务结束(commit,rollback);客户端连接断开。

  • 如果一个事务一直未释放锁,其他事务会被阻塞多久?会不会永远等待下去?如果

    是,在并发访问比较高的情况下,如果大量事务因无法立即获得所需的锁而挂起,会占

    用大量计算机资源,造成严重性能问题,甚至拖跨数据库。

[Err] 1205 - Lock wait timeout exceeded; try restarting transaction

-- 查看系统锁释放的时间
show VARIABLES like ‘innodb_lock_wait_timeout‘;
死锁的发生和检测

为什么可以直接检测到呢?

是因为死锁的发生需要满足一定的条件,所以在发生死 锁时,InnoDB 一般都能通过算法(wait-for graph)自动检测到。

那么死锁需要满足什么条件?

(1)因为锁本身是互斥的:同一时刻只能有一个事务持有这把锁,

(2)其他的事务需要在这个事务释放锁之后才能获取锁,而不可以强行剥夺,

(3)当多个事务形成等 待环路的时候,即发生死锁

查看锁信息(日志)
show status like ‘innodb_row_lock_%‘;

Innodb_row_lock_current_waits:当前正在等待锁定的数量;

Innodb_row_lock_time :从系统启动到现在锁定的总时间长度,单位 ms;

Innodb_row_lock_time_avg :每次等待所花平均时间;

Innodb_row_lock_time_max:从系统启动到现在等待最长的一次所花的时间;

Innodb_row_lock_waits :从系统启动到现在总共等待的次数。

-- 当前运行的所有事务 ,还有具体的语句
select * from information_schema.INNODB_TRX; 
-- 当前出现的锁
select * from information_schema.INNODB_LOCKS; 
-- 锁等待的对应关系
select * from information_schema.INNODB_LOCK_WAITS; 

? 如果一个事务长时间持有锁不释放,可以 kill 事务对应的线程 ID,也就是 INNODB_TRX 表中的 trx_mysql_thread_id,例如执行 kill 4,kill 7,kill 8。 当然,死锁的问题不能每次都靠 kill 线程来解决,这是治标不治本的行为。我们应该尽量在应用端,也就是在编码的过程中避免

如何避免死锁

1、 在程序中,操作多张表时,尽量以相同的顺序来访问(避免形成等待环路);

2、 批量操作单张表数据的时候,先对数据进行排序(避免形成等待环路);

3、 申请足够级别的锁,如果要操作数据,就申请排它锁;

4、 尽量使用索引访问数据,避免没有 where 条件的操作,避免锁表;

5、 如果可以,大事务化成小事务;

6、 使用等值查询而不是范围查询查询数据,命中记录,避免间隙锁对并发的影响。

原文 https://www.cnblogs.com/liweiweicode/p/12674306.html

MySQL的事务与锁 转

标签:starting   手工   mod   personal   https   red   pre   语句   serial   

原文地址:https://www.cnblogs.com/php-linux/p/13258742.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有
迷上了代码!