MySQL事务隔离级别
-- SERIALIZABLE serializable 序列化 ；一个个事务排成序列的形式。事务一个挨一个执行，等待前一个事务执行完，后面的事务才可以顺序执行
-- REPEATEABLE READ repeatable read 可重复读 ；
-- READ COMMITED read committed 提交的可读；(oracle默认)
-- READ UNCOMMITED read uncommitted 未提交的可读；（mysql 默认）别的事务可以查看的到使用 当前事务还没提交的 数据；会 脏读，幻读，不可重复读。
mysql 的serializable序列化隔离级别所导致问题的模拟
首先，创建一张表来通过对该表的操作来实现
CREATE TABLE `software` (
`sid` int(11) DEFAULT NULL,
`version` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
写入一条记录 insert into (sid,version) values (1,1);
同事开启两个事务 事务A 事务B；
1，创建第一个mysql连接，设置当前会话的隔离级别为 serializable;开启一个事务A，查看software表中有一条记录；
2.再创建一个新mysql连接，设置当前会话的隔离级别为 serializable;开启一个事务B，查看software表中有一条记录；
3.回到事务A的mysql会话中执行 向software表插入一条数据；
此时，事务A会执行失败，提示超时了。失败原因是，因为事务B也是serializable隔离级别的，并且还没被提交。serializable隔离级别的多个事务不可以同事对同一张表修改！
4.事务B执行commit；
5.事务A重新执行插入一条记录:insert into software (sid,version) values (2,1);
事务A此时执行成功了！
结论：serializable隔离级别的多个事务不可以同事对同一张表修改！
另外：当事务A执行的过程中如果对software表有update操作，事务B也不可以对事务A用到的表software表进行查询操作！
1.事务A与事务B同时都只对software表做查询 select 操作，不会导致死锁，可以查询出结果！
同时开启事务A，事务B，然后执行查询操作
1）事务A，
2）事务B，
3）事务A，
4)事务B,
2.事务A与事务B，都对software表做了查询操作，则事务A或者事务B不可以对software做修改，插入的操作了，因为会出现死锁的问题！
同时开启事务A ，事务B ；然后执行查询操作！
1）事务A
2）事务B
3）事务A
4）事务B
5）事务A
此时事务A对software执行update 或者 insert 操作 都会失败, serializable 序列化 隔离级别，会造成表级锁，对所有的记录都不可以修改！
总结：在SERIALIZABLE级别下，不会使用mysql的mvcc机制，而是在每一个select请求下获得读锁，在每一个update操作下尝试获得写锁。
只有当事务A将对表software的update操作，insert操作 commit之后， 事务B才能看到 事务A对表作出的修改！
