数据库—隔离级别

事务：事务是指数据库的一系列的逻辑操作，这组操作执行要么完全成功，要么全部失败。

• 事务的管理：在默认的情况下，数据库会自动开启并管理事务，光里的方式是每一句sql语句表示一个事务，如果想要实现对个sql语句实现事务的管理，需要自己手动开启并且管理事务：

start transaction; // 开启事务

commit;// 提交事务

rollback; //回滚事务

在JDBC中管理事务代码：

conn.setAutoCommit(false); // 关闭自动提交事务

.... // 执行sql语句 

conn.commit(); 

SavePoint sp = conn.setSavePoint();

conn.roolBack();

• 事务四大特性（ACID）：一个良好的数据库都保证我们具有这四大特性。

1. 原子性（Atomicity）： 原子性表示一个事务是不可分割的一部分，事务中的操作要么全部完成，要么全部失败。
2. 一致性（Consistency）：如果数据库在执行事务前是一个完整的状态，执行事务后任然保持一个完整性状态：（完整性状态：表示数据库中的各个表以及所有数据的约束保持不变）。
3. 隔离性(Isolation): 事务的隔离性表示当多个线程或者用户同时开启事务操作数据时，各个事务需要隔离，互不影响。
4. 持久性（Durability）： 当一个事务执行后，对数据库的改变是永久的不会再发生改变。

隔离性：

将数据库设计成单线程的数据库,可以防止所有的线程安全问题,自然就保证了隔离性.但是如果数据库设计成这样,那么效率就会极其低下.

数据库中的锁机制:

• 共享锁:

在非Serializable隔离级别做查询不加任何锁,而在Serializable隔离级
别下做的查询加共享锁,

共享锁的特点: 共享锁和共享锁可以共存,但是共享锁和排他锁不能共存
排他锁:在所有隔离级别下进行增删改的操作都会加排他锁,
排他锁的特点:和任意其他锁都不能共存

如果是两个线程并发修改,一定会互相捣乱,这时必须利用锁机制防止多个线程的并发修改

如果两个线程并发查询,没有线程安全问题

如果两个线程一个修改,一个查询......

四大隔离级别:

• Read uncommitted -- 不防止任何隔离性问题,具有脏读/不可重复度/虚读(幻读)问题
• Read committed -- 可以防止脏读问题,但是不能防止不可重复度/虚读(幻读)问题
• Repeatable read -- 可以防止脏读/不可重复读问题,但是不能防止虚读(幻读)问题
• Serializable -- 数据库被设计为单线程数据库,可以防止上述所有问题

从安全性上考虑: Serializable>Repeatable read>read committed>read uncommitted

从效率上考虑: read uncommitted>read committed>Repeatable read>Serializable

真正使用数据的时候,根据自己使用数据库的需求,综合分析对安全性和对效率的要求,选择一个隔离级别使数据库运行在这个隔离级别上.

mysql 默认下就是Repeatable read隔离级别,oracle 默认下就是read committed个隔离级别

查询当前数据库的隔离级别:select @@tx_isolation;
设置隔离级别:set [global/session] transaction isolation level xxxx;其中如果不写默认是session指的是修改当前客户端和数据库交互时的隔离级别,而如果使用golbal,则修改的是数据库的默认隔离级别。

脏读（将隔离级别设置为最低级 read uncommitted）：

模拟a向b转账：

A客户端（执行转款）：

QQ截图20170929111854.png

B客户端：（查询余额）：

QQ截图20170929112511.png

查询余额：

不可重复读 --------- 行级别的问题：

A客户端：

B客户端：

QQ截图20170929113313.png

查询账户每个人的平均账户余额：

虚读（幻读） --------- 表级别的问题：

A客户端：

QQ截图20170929114557.png

B客户端：

QQ截图20170929114750.png

更新丢失问题:
两个线程基于同一个查询结果进行修改,后修改的人会将先修改人的修改覆盖掉.

悲观锁: 悲观锁悲观的认为每一次操作都会造成更新丢失问题,在每次查询时就加上排他锁
乐观锁: 乐观锁会乐观的认为每次查询都不会造成更新丢失.利用一个版本字段进行控制

              查询非常多,修改非常少,使用乐观锁
              修改非常多,查询非常少,使用悲观锁