5.MySQL对事务的支持情况：
5.1. 查看存储引擎对事务的支持情况 ：
- 1.
SHOW ENGINES命令来查看当前 MySQL 支持的存储引擎都有哪些，以及这些存储引擎是否支持事务 - 2.下图可以能看出
在 MySQL 中，只有InnoDB类型的存储引擎是支持事务的
5.2.MySQL支持的四种隔离级别
不同的数据库厂商对SQL标准中规定的四种隔离级别支持不一样。比如,Oracle就只支持READ COMNITTED（默认隔离级别〉和SERIALIZABLE隔离级别
MySQL虽然支持4种隔离级别，但与SQL标准中所规定的各级隔离级别允许发生的问题却有些出入，
MySQL在REPEATABLE READ隔离级别下，是可以禁止幻读问题的发生的，禁
a.MySQL的默认隔离级别:
# 查看隔离级别，MySQL 5.7.20的版本之前：
SHOW VARIABLES LIKE 'tx_isolation';
/*
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| tx_isolation | REPEATABLE-READ |
+---------------+-----------------+
*/
# MySQL 5.7.20版本之后，引入transaction_isolation来替换tx_isolation
# 查看隔离级别，MySQL 5.7.20的版本及之后：
SHOW VARIABLES LIKE 'transaction_isolation';
/*
+-----------------------+-----------------+
| Variable_name | Value |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
*/
#或者不同MySQL版本中都可以使用的：
SELECT @@transaction_isolation;
/*
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ |
+-------------------------+
*/5.3.,MySQL中如何设置事务的隔离级别
a.更改隔离级别的语句：
b.关于设置时使用GLOBAL或SESSION的影响：
- 1.使用 GLOBAL 关键字（
在全局范围影响）：- 对当前已经存在的会话无效：当前会话是sessionA ，那对A无效，仅仅对SessionB,SessionC这样的新会话有效果
- 只对
执行完该语句之后产生的会话起作 用SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; #或 SET GLOBAL TRANSACTION_ISOLATION = 'SERIALIZABLE';
- 2.使用
SESSION关键字（在会话范围影响）：对当前会话的所有后续的事务有效- 如果在
事务之间执行，则对后续的事务有效
- 该语句可以在已经开启的事务中间执行，但不会影响当前正在执行的事务
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; #或 SET SESSION TRANSACTION_ISOLATION = 'SERIALIZABLE';
小结：数据库规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性就越好，但并发性越弱
3.6.GLOBAL和Session的演示
a.GLOBAL演示：
- 1.先看会话1：设置隔离级别
- 2.在去会话2：查看新的隔离级别
- 3.3.再回到会话1：重启会话1后，发现是新的隔离级别
b.SESSION 演示：
- 1.会话1：设置隔离级别并查看
- 2.会话2：
3.7.不同隔离级别举例:
a.数据准备：
- 1.创建数据表并且导入数据：
b. 演示1：READ UNCOMMITTED``读未提交之脏读
- 1.设置隔离级别为未提交读：
- 2.事务1和事务2的执行流程如下：
c.演示2:读已提交:READ COMMITTED：
d.演示3：可重复读``REPEATABLE READ
-
1.举例1：可以解决脏读，可重复度的问题
-
2.举例2：这种情况会有
幻读的情况：
-
1.这里要灵活的理解读取的意思。第一次select是读取，第二次的insert其实也属于隐式的读取，只不过是在mysql的机制中读取的，插入数据也是要先读取一下有没有主键冲突才能决定是否执行插入
-
2.幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些: select某记录是否存在，不存在，准备插入此记录，但执行insert时发现此记录已存在，无法插入，此时就发生了幻读。
-
3.在RR隔离级别下，step1、step2是会正常执行的，step3则会报错主键冲突，对于事务1的业务来说是执行失败的，这里事务1就是发生了幻读，因为事务1在step1中读取的数据状态并不能支撑后续的业务操作，事务1:“见鬼了，我刚才读到的结果应该可以支持我这样操作才对啊，为什么现在不可以"。事务1不敢相信的又执行了step4，发现和setp1读取的结果是一样的（RR下的 MVCC机制)。此时，幻读无疑已经发生，事务1无论读取多少次，都查不到id=3的记录，但它的确无法插入这条他通过读取来认定不存在的记录（此数据已被事务2插入)，对于事务1来说，它幻读了。
-
4.其实RR（Mysql默认隔离级别）也是可以避免幻读的，通过对select操作手动加行X锁(独占锁) (SELECT … FOR UPDATE这也正是SERIALIZABLE 隔离级别下会隐式为你做的事情)，同时，即便当前记录不存在，比如id = 3是不存在的，当前事务也会获得一把记录锁（因为InnoDB的行锁锁定的是索引，故记录实体存在与否没关系，存在就加行X锁，不存在就加间隙领），其他事务则无法插入此索引的记录，故杜绝了幻读。
-
5.在SERIALIZABLE隔离级别下，step1执行时是会隐式的添加行(X)锁/gap(X)锁的，从而step2会被阻塞，step3 会正常执行，待事务1提交后，事务2才能继续执行（主键冲突执行失败)，对于事务1来说业务是正确的，成功的阻塞扼杀了扰乱业务的事务2，对于事务1来说他前期读取的结果是可以支撑其后续业务的。
-
6.所以MySQL的幻读并非什么读取两次返回结果集不同，而是事务在插入事先检测不存在的记录时，惊奇的发现这些数据已经存在了，之前的检测读获取到的数据如同鬼影一般
