事务的四个特性&隔离级别

转载

隔离性:

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

数据库在想不保证隔离性，可能会发生的情况：如果是两个线程并发修改,一定会互相捣乱,这时必须利用锁机制防止多个线程的并发修改。如果两个线程并发查询,没有线程安全问题。如果两个线程一个修改,一个查询，就会导致脏读，不可重复读，虚读（幻读）。具体想做什么级别的控制，数据库无法帮我们做主，让我们自己决定。

脏读:一个事务读取到另一个事务未提交的数据（比如A和B买鞋，A汇钱给B，汇钱这个操作还没有提交，A告诉B我打钱了，B查了一下，发现了A的汇的钱。给了A鞋子，A立刻回滚，B发现自己账户上面没有钱）

不可重复读:在一个事务内读取表中的某一行数据，多次读取结果不同— 行级别的问题（A在银行里面活期有1000元，定期有1000，固定资产有1000。B是银行职员，上司B查一下A在银行行里面总共有多少钱。B查到A活期，定期，固定资各1000.因为并发执行，这时A刚好过来取走了活期1000元，B此时在并发执行，统计A的总钱数，发现是2000元。B提交给上司，上司发现钱数目不对）

虚读(幻读):是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致 — 表级别的问题（A银行账户1000元，B有1000元。D是银行业务人员，上司让D统计银行到底总共有多少钱，每个人有多少钱。D查询，发现总共2000元，银行用户总共2人，D刚要算平均值时。C来了，向银行里面存了4000元，D此时再算平均钱，结果是每人2000元。结果上次发现前后数据又不一致）。

对于这些情况，并发修改，数据库肯定要用锁。并发查询，没问题。一个修改，一个查询，数据库提供了四大隔离级别。

四大隔离级别:

Read uncommitted – 不防止任何隔离性问题,具有脏读/不可重复度/虚读(幻读)问题

Read committed – 可以防止脏读问题,但是不能防止不可重复度/虚读(幻读)问题

Repeatable read – 可以防止脏读/不可重复读问题,但是不能防止虚读(幻读)问题

Serializable – 数据库被设计为单线程数据库,可以防止上述所有问题

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

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

真正使用数据的时候,根据自己使用数据库的需求,综合分析对安全性和对效率的要求,选择一个隔离级别使数据库运行在这个隔离级别上.mysql 默认下就是Repeatable read隔离级别，oracle 默认下就是read committed个隔离级别。

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

数据库中的锁机制:

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

共享锁的特点:共享锁和共享锁可以共存,但是共享锁和排他锁不能共存

排他锁（互斥锁、写锁）:在所有隔离级别下进行增删改的操作都会加排他锁,

排他锁的特点:和任意其他锁都不能共存

Serialize级别下，你要查询，加共享锁。现在另一个人想要修改数据，需要排他锁。共享锁和排他锁不能共存，所以只能先查数据，另一个人等你查完在修改。自然不会有脏读、虚读、幻读等问题。任意级别下，两个线程要并发修改数据，需要排他锁，只要有一个线程修改，其他线程不可修改，需要等待。在非serialize级别下，查询不需要锁，修改要排他锁，可能会有脏读、虚读、幻读等问题。A和B在serialize级别下，都在查询数据，各有一个共享锁。现在A想要修改数据，共享锁升级为排他锁，需要等待B释放共享锁。B也要修改数据。共享锁升级为排他锁，需要等待A释放共享锁。造成死锁，mysql会在死锁发生时，结束造成死锁的一段，让另一端运行。

---

原子性：一个事务为一个最小的工作单元,整个事务中的所有操作要么全部成功(提交),要么全部失败(回滚).

一致性：(回滚)后的数据和原来的一致。

隔离性：事务和事务之间不干扰。一个事务必须与另外一个事务的执行结果隔离开。

持久性：执行成功。持久化数据。