数据库的隔离级别以及锁的关系的思考

前言

       1.乐观锁和悲观锁 与 数据库的隔离级别的关系 或者两者使用的场景是什么？

       我在网上所能找到的答案，帮助个人的理解。

       答案一：事务隔离级别是并发控制的整体解决方案，其实际上是综合利用各种类型的锁和行版本控制，来解决并发问题。锁是数据库并发控制的内部机制，是基础。对用户来说，只有当事务隔离级别无法解决一些并发问题和需求时，才有必要在语句中手动设置锁。

       那么事务隔离级别无法解决哪些并发问题呢？   

      先来看看事务的隔离级别：     

   事务隔离级别

   为了解决多个事务并发会引发的问题，进行并发控制。数据库系统提供了四种事务隔离级别供用户选择。

• Read Uncommitted 读未提交：不允许第一类更新丢失。允许脏读，不隔离事务。
• Read Committed 读已提交：不允许脏读，允许不可重复读。
• Repeatable Read 可重复读：不允许不可重复读。但可能出现幻读。
• Serializable 串行化：所有的增删改查串行执行。

  读未提交

 事务读不阻塞其他事务读和写，事务写阻塞其他事务写但不阻塞读。
 可以通过写操作加“持续-X锁”实现。

 读已提交

 事务读不会阻塞其他事务读和写，事务写会阻塞其他事务读和写。
 可以通过写操作加“持续-X”锁，读操作加“临时-S锁”实现。

可重复读

事务读会阻塞其他事务事务写但不阻塞读，事务写会阻塞其他事务读和写。
可以通过写操作加“持续-X”锁，读操作加“持续-S锁”实现。

串行化

“行级锁”做不到，需使用“表级锁”。

可串行化

如果一个并行调度的结果等价于某一个串行调度的结果，那么这个并行调度是可串行化的。

区分事务隔离级别是为了解决脏读、不可重复读和幻读三个问题的。

事务隔离级别	回滚覆盖	脏读	不可重复读	提交覆盖	幻读
读未提交	x	可能发生	可能发生	可能发生	可能发生
读已提交	x	x	可能发生	可能发生	可能发生
可重复读	x	x	x	x	可能发生
串行化	x	x	x	x	x

既然事务的隔离级别可以做到这些。还需要悲观锁干什么呢？

我的理解是：（理解有错误的，请大家指正）

Mysql默认使用的隔离级别是：可重复读

MSSQL默认使用的隔离级别是：读已提交

如果在MSSQL使用默认使用的隔离级别时读已提交的同事也想开发过程中想解决：不可重复读，提交覆盖和幻读等问题就可以使用悲观锁实现。

MYSQL同理。