mysql+Spring数据库隔离级别与性能分析

这里以mysql为例，先明确以下几个问题：

一.一般项目如果不自己配置事务的话，一般默认的是autocommit，即执行完一个操作后自动commit，提交事务。

（注：事务是绑定在数据库操作上的，也就是当程序执行（statement.excute等操作）转而到数据库层面上的时候，事务才开始发生）
当然spring可以将几个数据库操作动作绑在一个事务中，这样就需要介绍下spring事务配置方法，下面介绍的是常用方法，其他方法网上有很多。
spring提供了很多事务配置的策略，很方便，简要介绍一下：

复制代码 代码如下:

 <property>
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>

一般spring配置事务都是以上的配法，具体参数的意思有不懂的上网自己查吧，那么需要注意以下几点：（题外话）
1.我习惯将事务配置在service上，这时需要注意，只有service中以save、update等开头的方法，配置的事务才有效果。如果service中的方法名不是以save等开头的，比如taskSave()方法，即使在实现类中调用了service中的update方法，配置事务也失效，我试过。
2.readOnly这个属性很有意思，因为用了它后，会自动将数据库的隔离级别提高了一级，由提交读变为重复读，这块我后面说明。

二.数据库隔离级别

数据库隔离级别主要有以下四个：不可提交读，提交读，重复读和序列化读（以下理解可以不看）。
1. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
     这种隔离级别会产生脏读，不可重复读和幻像读。
2. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据
3. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
     它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
4. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
     除了防止脏读，不可重复读外，还避免了幻像读。
mysql默认的隔离级别是重复读，即 ISOLATION_REPEATABLE_READ。

注意：其中未提交读与序列化读不常用，未提交读危险性太高，会读到很多脏数据。而可串行化读是通过将读取的每一行数据加锁，以耗费性能为代价换取的，所以使用也很少，大部分数据库的隔离级别是提交读，比如oracle、sqlserver。而mysql默认的数据隔离级别是可重复读。

下面我来结合项目分析以下调整数据库隔离级别对性能的影响：
本地mysql数据库由ISOLATION_REPEATABLE_READ级别降低到ISOLATION_READ_COMMITTED级别：

场景：未用Spring，用户A在一个事务中对数据库发出两次查询请求，在两次查询之间，用户B对数据库的记录进行修改。

结果：ISOLATION_REPEATABLE_READ级别：用户A两次查询结果不一样。

          ISOLATION_READ_COMMITTED级别：用户A两次查询结果一样，因为对记录进行了加锁操作。

以task模块为例，在本地运行任务首页，通过对比分析两种事务处理方式得到如下结果(每次统计数据前均清理浏览器缓存，统计3次取平均值)：