简单介绍关于数据库事务的四种隔离级别

四种隔离级别分别是：
1、读未提交（Read UnCommit），2、读已提交（Read Commit），3、可重复读（Repeatable Read），4、串行化（Serializable）
问：简单介绍一下这四种隔离级别的作用和可能出现的问题，为什么？怎么解决？

答：（1）读未提交（Read UnCommit），A事务可以读取到B事务修改但未提交的数据，目前没有什么作用，但是效率出奇的高，事务的执行没有任何阻碍，目前没见过哪个项目用这种隔离级别，也没有数据库默认使用这种隔离级别。
很显然，读取不受提交的限制，B在A读取到数据之后回滚，自然会出现脏读现象。

（2）读已提交（Read Commit），B事务对数据的修改，如果没有提交，A事务只能访问B修改之前的数据，B一旦提交，A立即可以访问修改之后的数据。这样就防止了脏读的现象。
然而正是由于B提交之前，所修改的数据不能被A访问到，因此会在一定程度上降低效率。但是安全性却得到了提高，因此有些数据库默认的隔离级别就是读已提交，例如：PlSql，Oracle等。
因为不可重复读现象并没有对数据安全造成太大的影响，同时也没有太多的降低执行效率。因此很多项目中，都使用读已提交的隔离级别。
很明显，在B提交前后两个时间段，A对数据的查询结果是不同的，所以，读已提交虽然会避免脏读现象，却会出现不可重复读的现象。

（3）可重复读（Repeatable Read），在A事务对数据进行访问的时候，会记录访问时的数据内容，此时就算其他事务对该数据进行修改，A事务访问到的数据依然不会变化。这样就能达到A事务在访问数据过程中保持数据的前后一致，因此避免了前后两次读取数据的结果不同，不可重复读现象得到解决。
虽然可重复读解决了脏读和不可重复读的现象，但是并没有对表格进行限制，因此在访问期间，可能会出现其他事务在表格中插入数据，导致A事务访问前后，出现了新插入的数据，但是貌似在访问之前并没有见过这条数据，像是产生了幻觉，因此会出现新的问题，就是幻读！

（4）串行化（Serializable），顾名思义，加锁，序列化，事务之间的访问排队进行，一个事务在访问期间，其他事务对表格没有任何访问权限，自然就避免了上述所有问题，但是却导致执行效率极其低下，但是具有绝对的数据安全。这也是银行等项目使用这种隔离级别的原因，也是银行交易反应慢的原因。

最后，对于项目中该如何选择隔离级别，看业务逻辑对安全性和效率的要求视情况而定，没有最好的，只有最合适的。