此文会以比较通俗的语言来介绍一个数据库的隔离级别分别是什么意思，每种隔离级别是如何实现的，又会带来什么样的问题。
大部分的程序猿应该都知道，数据库中有四种隔离级别，分别是读未提交(Read Uncommited)，读已提交(Read Committed), 可重复读(Repeatable Read)和串行化(SERIALIZABLE)。除了最后一个以性能为代价换取读写安全一致的串行化外，其他三种类型都会有各自在并发读写场景下的一些问题。
Read Uncommitted
先从这个最不安全的说起，Read Uncommitted顾名思义就是允许读取其他事务还未提交的更新操作。这个隔离级别会带来脏读，不可重复读，幻读一系列的问题。说到这里有必要先解释下什么是脏读，不可重复读和幻读。
- 脏读
想一下这样的一个例子，你在淘宝上拍了一件100元的商品，正准备去付款。这个时候卖家本想对这件商品做一个减价50元的操作，可是由于误操作选成了涨价50元，所幸的是还未提交。卖家发现了这个问题准备撤销，然后在这个时候付款程序却读到了这个未提交的涨价50元操作并付了款。当你发现的时候去再一次查看商品价格的时候发现还是100元，因为卖家撤销了刚才的操作。 - 不可重复读
依然是淘宝买东西的例子，你拍下了一件100元的商品还没付款，这个时候卖家却自说自话的去改了价格变成了150元。然后当你付款的时候你会惊讶的发现这件商品莫名其妙的涨价了50元。 - 幻读
想象一下你是一个淘宝卖家，然后你想对店铺里的所有商品做一个降价50的操作。你全选了所有商品，选择了降价按钮，输入了50元。然后在你提交之前，有一个客服往店铺里面添加了一个新的商品。当你提交之后你会发现刚才的降价操作竟然没有对所有的商品生效(就是指那个新添加的商品)，好像之前的全选漏掉了一个商品似的。
说到这里，大家应该可以明白为什么Read Uncommitted会发生所有上述这三种问题了吧。它都能读取别人还没有保存的东西了，这能不出问题吗。。
Read Committed
读已提交解决了脏读的问题，以上面脏读中的场景为例，当你设置了读已提交级别之后，数据库会保证你只能读到那些已经提交的值。如果有一个事务正在修改某一条记录，数据库会给这条记录加上一个排他锁，意思是只有当前事务可以访问这条记录，其他要访问的人都先等着，等我改完了你再去弄你的事。
但是这个级别依然无法解决不可重复读和幻读的问题，拿不可重复读来说，我有一个事务A先读取了一条包含金额为100的记录，想对它做一个降价50元的操作。同时有一个事务B对这条记录做了一个涨价50的操作并且提交。这个时候事务A如果在去读一次数据库就会发现金额变成了150，和之前不一样了。
Repeatable Read
可重复读级别解决了不可重复读的问题，数据库会在程序读数据的时候加上一个共享锁(读的程序可以共享某条记录，但是写就不行)，在程序写数据的时候加上一个排他锁(一加上排他锁，其他程序读或者写都不行了)。这样一来，大家想像是不是就能解决可重复读的问题了？以上面的场景为例，在事务A读取了金额为100的记录的时候，数据库会给这条记录加上一个共享锁，也就是说事务B是不可能对这条记录进行修改的，直到事务A释放了锁以后。
Serializable
最后这个也是最严苛的事务隔离机制，可以理解为只要有一个程序在操作某条记录，无论是读或者写，其他所有的程序都必须等着直到之前那个程序完成事务。这个事务隔离级别会严重影响性能，试想一下双11的时候成千上万的用户在浏览淘宝，每个用户必须先等待之前用户的读取(商品数据等)完成之后服务器才能响应是一种什么样的体验。
