22. 数据库的隔离级别和锁机制

数据库的隔离级别和锁机制

一、数据库隔离级别

1. 隔离级别说明

隔离级别是基于客户端来讨论的，不同的客户端在和服务器交互式可以有不同的隔离级别，客户端处在什么隔离级别就具有什么隔离级别的问题。mysql数据库的隔离级别一共有四种.

标志	名称	说明
read uncommitted	读未提交	不做任何隔离。可能产生脏读,不可重复读,虚读/幻读问题性能最好。
read committed	读已提交	一个事务可以读取到另一个事务已经提交的数据。可以防止脏读，但可能存在不可重复读,虚读/幻读问题,性能较好。
repeatable read	可重复读取	在查询整表数据时，一个事务可以读取到另一个事务已经提交的数据。可以防止脏读不可重复读问题，但可能存在虚读/幻读问题。mysql默认采用此隔离级别。性能一般。
serializable	序列化	通过锁进行严格隔离，对同一个数据的访问要串行化进行。可以防止脏读，不可重复读，虚读/幻读问题。但数据库处于串行化状态，效率极其低下。性能最差。

2. 如何选择隔离级别

1. 选择不同的隔离级别，就可以防止在并发读写的过程中的不同的隔离性问题，隔离级别设置的越严格，防止的问题就越多但性能就越低，隔离级别设置的越宽松，性能就越好但可能产生的隔离性问题就越多
2. 数据库使用者应该根据自己的需求选择一个合理的隔离级别，选择一个能够防止想要防止的问题的情况下性能尽量好的隔离级别。
3. 从可靠性角度:serializable > repeatable read -> read committed -> read uncommitted
4. 从性能角度:read uncommitted -> read committed -> repeatable read ->serializable
5. 在真正的开发中 脏读问题太严重，所以read uncommitted很少用。serializable性能太差，也很少用。所以只需根据是否需要防止不可重复读，在read committed 和repeatable read之间选择一个即可。在实际开发中 repeatable read用的跟多一些。

3. 查询当前客户端隔离级别的命令.

select @@tx isolation;

4. 修改隔离的命令

set[session/global] transaction isolation level 隔离级别名称;1. 可以通过选择[session]来指定修改的是当前客户端的隔离级别，mysql服务器默认的隔离级别不变。
2. 可以通过选择[global来指定修改的是mysl服务器默认的隔离级别，当前客户端隔离级别不变，默认不写就是[global)

二、数据库中的锁

1. 共享锁、排他锁

数据库也是用锁来保证数据隔离的，但是为了数据库的锁设计的更加精细。体现在数据库中的锁分为共享锁和排他锁

1. 共享锁和共享锁可以共存，共享锁和排他锁不能共存
2. 排他锁和任何锁都不能共存
3. 在非serializable隔离级别下，查询不加锁
4. 在Serializable隔离级别下，查询加共享锁。
5. 任意隔离级别下增删改加排他锁。

正是利用了这种锁机制，数据库保证了并发的读不隔离，并发的写一定隔离，并发的读写在某一方或多方为Serializable的级别时，实现串行化，保证完全可靠。

2. 死锁

多个客户端都是serializable的级别下，先查询再修改，可能会进入与相等待状态，其实就是发生了死锁，mysql会检测到死锁，自动退出一方以打断死锁。

3. 行级锁、表级锁

数据库的锁根据锁定的粒度可以分为行级锁和表级锁。行级锁锁一行。表级锁锁整表。数据库自动根据操作的数据决定加哪种粒度的

三、解决更新丢失问题

1. 解决方案

1. 修改隔离级别为Serializablea。将数据库的隔离级别设置为Serializable即可完全防止更新丢失问题但通常基于效率的考虑，数据库的隔离级别不会设置为Serializable.此时要选择其他的解决方案
2. 悲观锁、乐观锁。在非Serializable隔离级别下，可以使用悲观锁、乐观锁来解决更新丢失。悲观锁、乐观锁并不是数据库中真正存在的锁，仅仅是更新丢失问题解决方案的名字。这个名字体现了在解决更新丢失问题时的思考的角度。

2. 乐观锁、悲观锁

1. 悲观锁悲观的认为每次查询都会造成更新丢失，则在查询时手动加上排他锁，从而在查询阶段就避免同时查询，从而避免更新丢失。在select语句后加上for update就可以手动增加排他锁。
2. 乐观锁乐观的认为每次查询都不会造成更新丢失，每次都正常执行查询，但为了防止可能的更新丢失造成危害，通常都会在表中额外设计一个额外版本字段，每次更新时版本字段都自增，且每次更新操作中必须基于上一个版本才做更新从而避免更新丢失造成的危害。

3. 乐观锁、悲观锁的选择

1. 悲观锁的缺点是一查就锁，查询多是效率低下
2. 乐观锁的缺点是，在大量的并发修改时，很容易造成修改失败，极端的情况下可能需要失败很多次才能完成修改,
3. 查询较多，修改较少，用乐观锁
4. 修改较多，查询较少，用悲观锁