数据库一般都会并发执行多个事务,多个事务可能并发的对相同的一批数据进行增删改查,此种情况下的操作就会导致脏写、脏读、不可重复读、幻读这些问题。
这些问题的本质都是数据库的多事务并发问题,为解决此问题,数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制机制,用一整套机制来解决多事务并发问题。
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。
当两个或多个事务操作同一行数据,然后基于最初选定的值进行更新该行数据,由于每个事物并不知道其他事物的存在,就会发生丢失更新问题(最后的更新覆盖了由其他事物所做的更新)。
一个事务对一条记录进行修改,且该事务未提交时,另一个事务也来读取同一条记录,如果不加以控制,第二个事务就读到了第一个事务的“脏”数据。即一个事务读取到了另一个事务未提交的数据。
一个事务在读取某些数据后,一段时间再次读取之前的读过的数据,发现读出的数据已经发生了改变,某些记录已经被删除了。即同一个事务中相同查询不同时刻读出的数据结果不一致,不符合隔离性。
一个事务按相同的条件重新读取以前检索过的数据,发现其他事务插入了满足其查询条件的新数据。即事务A读取到了事务B提交的新增数据,不符合隔离性。
并发事务带来的问题其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
读未提交(Read uncommitted) | 可能 | 可能 | 可能 |
读已提交(Read committed) | 不可能 | 可能 | 可能 |
可重复读(Repeatable read) | 不可能 | 不可能 | 可能 |
串行化(Serializable) | 不可能 | 不可能 | 不可能 |
数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度 上“串行化”进行,这显然与“并发”是矛盾的。 同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不 敏感,可能更关心数据并发访问的能力。
常看当前数据库的事务隔离级别: show variables like ‘tx_isolation’;
设置事务隔离级别:set tx_isolation=‘REPEATABLE-READ’;
Mysql默认的事务隔离级别是可重复读,用Spring开发程序时,如果不设置隔离级别默认用Mysql设置的隔 离级别,如果Spring设置了就用已经设置的隔离级别。
在数据库中,除了传统的计算资源(如CPU、RAM、I/O等)的争用以外,数据也是一种供需要用户共享的资 源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发 访问性能的一个重要因素。
每次操作锁住整张表。开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低; 一般用在整表数据迁移的场景。
lock table 表名称 read(write),表名称2 read(write);
show open tables;
unlock tables;
当前session和其他session都可以读该表 当前session中插入或者更新锁定的表都会报错,其他session插入或更新则会等待
当前session对该表的增删改查都没有问题,其他session对该表的所有操作被阻塞
总结:
1、对MyISAM表的读操作(加读锁) ,不会阻寒其他进程对同一表的读请求,但会阻赛对同一表的写请求。只有当 读锁释放后,才会执行其它进程的写操作。
2、对MylSAM表的写操作(加写锁) ,会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其它进 程的读写操作。
每次操作锁住一行数据。开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度最高。
InnoDB与MYISAM的最大不同有两点:
一个session开启事务更新不提交,另一个session更新同一条记录会阻塞,更新不同记录不会阻塞
总结:
MyISAM在执行查询语句SELECT前,会自动给涉及的所有表加读锁,在执行update、insert、delete操作会自 动给涉及的表加写锁。 InnoDB在执行查询语句SELECT时(非串行隔离级别),不会加锁。但是update、insert、delete操作会加行 锁。简而言之,就是读锁会阻塞写,但是不会阻塞读。而写锁则会把读和写都阻塞。