MySQL系列-高级-深入理解Mysql事务隔离级别与锁机制01
MySQL系列-高级-深入理解Mysql事务隔离级别与锁机制01
MySQL系列-高级-深入理解Mysql事务隔离级别与锁机制
本文参考诸葛老师的MySQL课与博主码拉松的博客MySQL行级锁效果演示
1. 概述
我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。 这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制，用一整套机制来解决多事务并发问题。接下来，我们会深入讲解这些机制，让大家彻底理解数据库内部的执行原理。
2.事务及其ACID属性
1. ACID
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。
原子性(Atomicity) ：事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。 一致性(Consistent) ：在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规 则都必须应用于事务的修改,以保持数据的完整性。 隔离性(Isolation) ：数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。 持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。
2. 并发事务处理带来的问题
更新丢失(Lost Update)或脏写 当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。 脏读（Dirty Reads） 一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。 一句话：事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。 不可重读（Non-Repeatable Reads） 一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。 一句话：事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性 幻读（Phantom Reads） 一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。 一句话：事务A读取到了事务B提交的新增数据，不符合隔离性
3. 事务隔离级别
“脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。
数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。 同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。 常看当前数据库的事务隔离级别:
show variables like 'tx_isolation';设置事务隔离级别：
set tx_isolation='REPEATABLE-READ';Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别
3. 锁
锁是计算机协调多个进程或线程并发访问某一资源的机制。 在数据库中，除了传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供需要用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。
1. 锁分类
从性能上分为乐观锁(用版本对比来实现)和悲观锁 从对数据操作的粒度分，分为表锁和行锁 从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)，还有意向锁
读锁（共享锁，S锁(Shared)）：针对同一份数据，多个读操作可以同时进行而不会互相影响，比如：
select * from T where id=1 lock in share mode写锁（排它锁，X锁(eXclusive)）：当前写操作没有完成前，它会阻断其他写锁和读锁，数据修改操作都会加写锁，查询也可以通过for update加写锁，比如：
select * from T where id=1 for update意向锁（Intention Lock）：又称I锁，针对表锁，主要是为了提高加表锁的效率，是mysql数据库自己加的。当有事务给表的数据行加了共享锁或排他锁，同时会给表设置一个标识，代表已经有行锁了，其他事务要想对表加表锁时，就不必逐行判断有没有行锁可能跟表锁冲突了，直接读这个标识就可以确定自己该不该加表锁。特别是表中的记录很多时，逐行判断加表锁的方式效率很低。而这个标识就是意向锁。 意向锁主要分为：
意向共享锁，IS锁，对整个表加共享锁之前，需要先获取到意向共享锁。 意向排他锁，IX锁，对整个表加排他锁之前，需要先获取到意向排他锁。
表锁 每次操作锁住整张表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低； 一般用在整表数据迁移的场景。 基本操作
-- 建表SQL
CREATE TABLE `mylock` (
`id` INT (11) NOT NULL AUTO_INCREMENT,
`NAME` VARCHAR (20) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE = MyISAM DEFAULT CHARSET = utf8;
-- 插入数据
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('1', 'a');
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('2', 'b');
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('3', 'c');
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('4', 'd');手动增加表锁
lock table 表名称 read(write),表名称2 read(write);查看表上加过的锁
show open tables;删除表锁
unlock tables;2. MylSAM表读/写锁案例分析
1. 读锁操作
给mylock表加读锁
LOCK TABLE mylock READ;输出为：
[SQL]-- SHOW OPEN TABLES;
LOCK TABLE mylock READ;
受影响的行: 0
时间: 0.001s当前session和其他session都可以读该表 当前session中插入或者更新锁定的表都会报错，其他session插入或更新则会等待 新打开一个session
INSERT INTO mylock VALUES(5,'e');此时等待，页面为：
在锁的session中，解锁
unlock TABLE;插入完成
2. 写锁操作
给mylock表加写锁
LOCK TABLE mylock WRITE;输出为：
[SQL]LOCK TABLE mylock WRITE;
受影响的行: 0
时间: 0.001s当前session对该表的增删改查都没有问题，其他session对该表的所有操作被阻塞 在当前session进行插入操作：
INSERT INTO mylock VALUES(6,'f');输出为：
新打开一个session，进行查询：
SELECT * FROM test.mylock ;输出为：
在锁的session中，解锁
unlock TABLE;注意，多次锁表，会卡住，如果这时无法进行操作，可以输入以下命令：
show full processlist;查看到锁住表的id，然后通过kill id杀掉，这个id即可。
kill 38
案例结论
1、对MyISAM表的读操作(加读锁) ,不会阻塞其他进程对同一表的读请求,但会阻塞对同一表的写请求。只有当 读锁释放后,才会执行其它进程的写操作。 2、对MylSAM表的写操作(加写锁) ,会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其它进 程的读写操作
3. InnoDB行锁案例分析
行锁介绍
每次操作锁住一行数据。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高。 InnoDB与MYISAM的最大不同有两点：
InnoDB支持事务（TRANSACTION） InnoDB支持行级锁
行锁演示 一个session开启事务更新不提交，另一个session更新同一条记录会阻塞，更新不同记录不会阻塞 总结： MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁,在执行update、insert、delete操作会自 动给涉及的表加写锁。 InnoDB在执行查询语句SELECT时(非串行隔离级别)，不会加锁。但是update、insert、delete操作会加行 锁。 简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞。
行锁演示
参考博客：MySQL行级锁效果演示 创建表
CREATE TABLE mylock_innodb ( id INT PRIMARY KEY, NAME VARCHAR ( 10 ) ) ENGINE = INNODB;
insert into mylock_innodb values(1,'a');
insert into mylock_innodb values(2,'b');
insert into mylock_innodb values(3,'c');演示一
1、打开一个会话窗口1，开启了一个事务，并执行更新操作，然后不对事务进行提交。
-- 开启事务
start transaction;
-- 更新id为1的数据
update mylock_innodb set name = 'a1' where id = 1;2、此时我再重新打开一个窗口2，还是开启一个事务，并对id为2的这一行执行更新操作，你会发现返回执行成功了。
-- 开启事务
start transaction;
-- 更新id为2的数据
update mylock_innodb set name = 'b2' where id = 2;输出为：
[SQL]-- 开启事务
start transaction;
受影响的行: 0
时间: 0.001s
[SQL]
-- 更新id为1的数据
update mylock_innodb set name = 'b2' where id = 2;
受影响的行: 1
时间: 0.001s3、当然如果你在窗口2，也执行更新id为1的这一行数据，那就会一直阻塞在那。
-- 更新id为1的数据
update mylock_innodb set name = 'a1_newsession' where id = 1;输出为：
4、直到窗口1，对事务进行提交或者回滚后，窗口2才会返回。
-- 执行COMMIT; 或 ROLLBACK;
COMMIT;但如果等待时间过长，窗口二会提示如下错误：
演示二
1、打开一个会话窗口1，开启了一个事务，并执行如下操作:
-- 开启事务
start transaction;
-- 执行查询
select * from mylock_innodb where id = 1 for update;
-- 不提交事务输出为：
2、再重新打开一个窗口2，还是开启一个事务，并对id为2的这一行执行操作：
-- 开启事务
start transaction;
-- 执行查询 窗口2
select * from mylock_innodb where id = 2 for update;
-- 不提交事务输出为：
执行成功了，这是因为id不同，相互操作不影响。 然后提交或回滚事务，避免影响接下来的操作。
演示三
1、打开窗口1，开启事务，执行如下操作，查询条件为name
-- 开启事务
start transaction;
-- 执行查询 窗口1
select * from mylock_innodb where NAME = 'c' for update;
-- 不提交事务2、打开窗口2，开启事务，执行如下操作，查询条件为name
-- 开启事务
start transaction;
-- 执行查询 窗口2
select * from mylock_innodb where NAME = 'a1' for update;
-- 不提交事务输出为：
这时，会发现窗口2阻塞了。
演示2和演示3的问题
通过id查询不同的行，不会受到影响，但通过name查询不同的行，为什么会互相影响呢？ 原因在于 for update 是一种排他锁。又可以称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。可以自行演示，非常简单。
这个排他锁的问题就在于，当明确查询带索引时，就是行锁，如果查询不带索引时，就是表锁，所以才出现了为什么用id查询时不影响，用name查询时就会阻塞，所以可以给name加上了索引后，再去尝试就不会阻塞了，有兴趣的朋友可以自行尝试，这里就不演示了。 总结
Innod支持的行锁，在共享锁，排他锁时，要注意查询时是否是通过索引来查询，如果不是，则还是会锁表。