让场景刻画云的样子

上图从上到下的模式会导致系统的并行性能依次降低，安全性依次提高。

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。

读已提交(Oracle默认)：别人改数据的事务已经提交，我在我的事务中才能读到。

可重复读(MySQL默认)：别人改数据的事务已经提交，我在我的事务中也不去读，以此保证重复读一致性。

串行：我的事务尚未提交，别人就别想改数据。

标准跟实现：上面都是关于事务的标准，但是每一种数据库都有不同的实现，比如MySQL InnDB 默认为RR级别，但是不会出现幻读。因为当事务A更新了所有记录的某个字段，此时事务A会获得对这个表的表锁，因为事务A还没有提交，所以事务A获得的锁没有释放，此时事务B在该表插入新记录，会因为无法获得该表的锁，则导致插入操作被阻塞。只有事务A提交了事务后，释放了锁，事务B才能进行接下去的操作。所以可以说 MySQL的RR级别的隔离是已经实现解决了脏读，不可重复读和幻读的。

5、MySQL中的锁

无论是Java的并发编程还是数据库的并发操作都会涉及到锁，研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想。

悲观锁：

优点：适合在写多读少的并发环境中使用，虽然无法维持非常高的性能，但是在乐观锁无法提更好的性能前提下，可以做到数据的安全性

缺点：加锁会增加系统开销，虽然能保证数据的安全，但数据处理吞吐量低，不适合在读书写少的场合下使用

乐观锁：

优点：在读多写少的并发场景下，可以避免数据库加锁的开销，提高DAO层的响应性能，很多情况下ORM工具都有带有乐观锁的实现，所以这些方法不一定需要我们人为的去实现。

缺点：在写多读少的并发场景下，即在写操作竞争激烈的情况下，会导致CAS多次重试，冲突频率过高，导致开销比悲观锁更高。

实现：数据库层面的乐观锁其实跟CAS思想类似， 通数据版本号或者时间戳也可以实现。

数据库并发场景主要有三种：

读-读：不存在任何问题，也不需要并发控制

读-写：有隔离性问题，可能遇到脏读，幻读，不可重复读

写-写：可能存更新丢失问题，比如第一类更新丢失，第二类更新丢失

两类更新丢失问题：

第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果

为了合理贯彻落实锁的思想，MySQL中引入了杂七杂八的各种锁：
 

输出：User{id=1, userName='tian', age=22}

注意：实体类的get set 和toString()方法这里给省略， 希望大家在使用的使用，使用快捷键很简单的就搞定了。

上面提到过resultType和resultMap，那么他们两到底有什么区别呢?

resultType和resultMap 有什么区别?

• resultType：直接表示返回类型， 包括基本数据类型和复杂数据类型。
• resultMap：外部resultMap定义的引用，通过对应的外部resultMap的id，表示结果映射到哪个resultMap上，一般用于字段名和属性名不一致的情况，或者需要做复杂的联合查询以便自由控制映射结果。

两者的关联

当进行查询时，查询出来的每个字段都会放在一个Map里，当查询元素返回属性是resultType的时候，会将键值对取出赋所指定的属性。其实MyBatis的每个查询映射的返回类型都是resultMap，只是当我们使用resultType的时候，会自动把对应的值赋给所指定的对象属性，当使用resultMap时候，因为map不是很好的表示领域，我们就进一步的转化为对应的实体对象。resultMap主要作用于复杂的联合查询上。

resultMap的自动映射级别：默认级别为PARTIAL，也可以在settings更改值。

注意：resultType和resultMap本质是一样的，都是Map数据结构，但是二者不能同时存在。

增删改案例

insert

 

（编辑：柳州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!