前言

为啥要有锁机制，其实是为了避免并发的各种乱七八糟的问题。

Mysql事务及ACID特性详解
Mysql事务隔离级别详解
Mysql锁机制详解
Mysql锁优化建议

一、ACID属性

1、原子性(Atomicity)

事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。

2、一致性(Consistent)

在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性。

3、隔离性(Isolation)

数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。

4、持久性(Durable)

事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

二、并发事务带来的问题

1、更新丢失(Lost Update)或脏写

当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。

2、脏读（Dirty Reads）

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。

一句话：事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。

3、不可重读（Non-Repeatable Reads）

一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。

一句话：事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性。

4、幻读（Phantom Reads）

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。

一句话：事务A读取到了事务B提交的新增数据，不符合隔离性。

三、Mysql锁详解

1、锁分类

从性能上分为乐观锁(用版本对比来实现)和悲观锁

从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)

读锁（共享锁，S锁(Shared)）：针对同一份数据，多个读操作可以同时进行而不会互相影响

写锁（排它锁，X锁(eXclusive)）：当前写操作没有完成前，它会阻断其他写锁和读锁

从对数据操作的粒度分，分为表锁和行锁

2、表锁

每次操作锁住整张表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

一般用在整表数据迁移和表备份的场景。

# 手动增加表锁
lock table 表名称 read(write),表名称2 read(write);
# 查看表上加过的锁
show open tables;
# 删除表锁
unlock tables;

3、行锁

每次操作锁住一行数据。开销大，加锁慢（先要找到那一行才能加锁）；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高。

InnoDB与MYISAM的最大不同有两点：

InnoDB支持事务（TRANSACTION）
InnoDB支持行级锁

MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁,在执行update、insert、delete操作会自动给涉及的表加写锁。

InnoDB在执行查询语句SELECT时(非串行隔离级别)，不会加锁。但是update、insert、delete操作会加行锁。

简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞。

四、隔离级别

隔离级别	脏读	不可重复读	幻读
读未提交	可能	可能	可能
读已提交	不可能	可能	可能
可重复读	不可能	不可能	可能
可串行化	不可能	不可能	不可能

1、读未提交（同一事务内，读到其他未提交事务的数据）

set tx_isolation='read-uncommitted';

客户端A在操作事务，事务还未提交，打开另外一个客户端B，更新表。

这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据。

一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据。

2、读已提交（同一事务内，读到其他已提交的数据）

set tx_isolation='read-committed';

客户端A在操作事务，事务还未提交，打开另外一个客户端B，更新表。

这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读的问题。

客户端B的事务提交，客户端A执行与之前相同的查询操作，结果与之前的不一致，即产生了不可重复读的问题。

3、可重复读（同一事务内，可以重复读某一个数据，该数据不会发生变化）

set tx_isolation='repeatable-read';

客户端A操作事务中，客户端B执行数据更新等操作；

客户端A查询表的所有记录，不会查出新增数据，所以没有出现幻读。

但是客户端A可以直接对客户端B插入的数据进行更新操作，不满足隔离性。

4、可串行化

set tx_isolation='serializable';

在同一个事务中，给所有语句都加锁了。开发中很少用，因为太重了，什么操作都加锁，并发度很低，性能较差。

五、锁的补充

1、间隙锁（Gap Lock）

间隙锁，锁的就是两个值之间的空隙。Mysql默认级别是repeatable-read，有可能出现幻读问题，间隙锁在某些情况下可以解决幻读。

假设account表里数据如下：

那么间隙就有 id 为 (3,10)，(10,20)，(20,正无穷) 这三个区间。

执行下面语句

update account set name = 'zhuge' where id > 8 and id <18;

其他Session没法在这个范围所包含的所有行记录(包括间隙行记录)以及行记录所在的间隙里插入或修改任何数据，即id在(3,20]区间都无法修改数据，注意最后那个20也是包含在内的。

间隙锁是在可重复读隔离级别下才会生效。

一句话总结，间隙锁就是锁住索引之间的间隙，保证数据一致性，解决幻读问题。

2、临键锁(Next-key Locks)

Next-Key Locks是行锁与间隙锁的组合。像上面那个例子里的这个(3,20]的整个区间可以叫做临键锁。

无索引行锁会升级为表锁，锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁

session1 执行：

update account set balance = 800 where name = 'lilei';

session2 对该表任一行操作都会阻塞住

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。

锁定某一行还可以用lock in share mode(共享锁) 和for update(排它锁)。

例如：

select * from test_innodb_lock where a = 2 for update;

这样其他session只能读这行数据，修改则会被阻塞，直到锁定新的session提交

六、锁优化建议

尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。
合理设计索引，尽量缩小锁的范围。
尽可能减少检索条件范围，避免间隙锁。
尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行。
尽可能低级别事务隔离。

深入浅出Mysql（五）-原来MySQL锁机制是这么回事

前言