白话：
    一般情况下我们会使用InnoDB作为存储引擎，InnoDB是支持事务的，多个事务可能同时做增删改查
    如果说他们对相同的数据（同一张表里面的某个数据）进行同时操作势必会产生并发问题，正是由于这种并发
    问题，mysql给我们设计了很多很多的机制来规避这种问题，比如说事务隔离机制，锁机制，MVCC多版本控制机制
    这一套套的并发机制可以让我们的数据库在很高的并发下仍然保证操作无误。

    ACID ——-事务的几大特性：
    原子性 ：事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
    一致性：在事务开始和完成时,事务里面数据都必须保持一致状态。这意味着所有相关的数据规
    则都必须应用于事务的修改,以保持数据的完整性。
    隔离性 ：数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独
    立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
    持久性：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

    并发事务处理带来的各种问题
    更新丢失(Lost Update)或脏写
    当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存
    在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新。
    脏读（Dirty Reads）
    一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这
    时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的
    处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。
    一句话：事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B
    事务回滚，A读取的数据无效，不符合一致性要求。
    不可重读（Non-Repeatable Reads）
    一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改
    变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。
    一句话：事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性
    幻读（Phantom Reads）
    一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数
    据，这种现象就称为“幻读”。
    一句话：事务A读取到了事务B提交的新增数据，不符合隔离性

    事务隔离级别
    如下图所示：
    image.png
    “脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制
    来解决。数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度
    上“串行化”进行,这显然与“并发”是矛盾的。
    同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读”和“幻读”并不
    敏感,可能更关心数据并发访问的能力。
    常看当前数据库的事务隔离级别: show variables like ‘tx_isolation’;
    image.png
    一般情况下互联网公司是可重复读级别。
    设置事务隔离级别：set tx_isolation=’REPEATABLE-READ’;
    Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔
    离级别，如果Spring设置了就用已经设置的隔离级别

    锁详解
    锁是计算机协调多个进程或线程并发访问某一资源的机制。
    在数据库中，除了传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供需要用户共享的资
    源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发
    访问性能的一个重要因素。 如果对于数据库中某条数据加了一把锁，除非等当前事务提交，否则别的事务是无法
    对当前事务进行修改的。

    锁分类
    从性能上分为乐观锁(用版本对比来实现)和悲观锁
    从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)
    读锁
    （共享锁，S锁(Shared)）：针对同一份数据，多个读操作可以同时进行而不会互相影响
    写锁
    （排它锁，X锁(eXclusive)）：当前写操作没有完成前，它会阻断其他写锁和读锁
    从对数据操作的粒度分，分为表锁和行锁
    表锁
    每次操作锁住整张表。开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；
    一般用在整表数据迁移的场景
    行锁
    每次操作锁住一行数据。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最
    高。
    InnoDB与MYISAM的最大不同有两点：
    InnoDB支持事务（
    TRANSACTION）
    InnoDB支持行级锁
    行锁演示
    一个session开启事务更新不提交，另一个session更新同一条记录会阻塞，更新不同记录不会阻塞

    行锁与事务隔离级别案例分析

    读未提交：*
    这里创建了一张表，表结构如下
    image.png
    开一个客户端A，设置当前的事务模式为read uncommitted(未提交读)，查询account的值
    set session transaction isolation level read uncommitted ;
    image.png
    start transaction ; 开始执行事务
    客户端select     from account ;
    客户端A查到的id为1的balance结果如下
    image.png
    在客户端A提交事务之前打开客户端B，更新表account：
    image.pngimage.pngimage.png
    这时发现客户端2已经将id=1的balance的值更新到400，我们在客户端1中select查看，发现值也变为400
    image.png
    但实际上，这个400，是客户端2还没有提交的数据，如果这时候后端开发人员拿400去做操作的话，400-50 = 350
    把350更新到数据库中之后，客户端2执行了rollback;之后，那么客户端1读到的数据就变为了脏数据。所以这就是脏数据
    的产生。
    此时，在客户端B执行rollback操作，将事务回滚。回滚之后客户端B执行查询，得到的结果为450 。
    image.pngimage.png
    这时在客户端A执行操作balance的减操作，操作如下
    UPDATE account SET balance = balance - 50 WHERE id = 1 ;
    select * from account;
    image.png
    如果在JAVA中，将第一次（脏读）取到的值来进行运算，其实是非常错误的，建议根据
    数据库中的表实时数据来进行取值，这样可有效避免脏读现象

    读已提交：
    打开客户端A，设置当前的事务模式为——读已提交

    set session transaction isolation level read committed ;

    image.png
    在客户端A上查看数据为400，这时开启客户端B，同样开启一个事务，对account表进行操作，将
    id为1的balance值减50，然后查询，不提交事务。
    image.pngimage.png
    在客户端B可以看到查询结果为350 ，再次回到客户端A上执行查询，结果仍然是400
    客户端B修改的数据客户端A无法查到
    image.png
    这样一来，便有效解决了脏读的问题。