初步结论：
1.数据库隔离级别是为了有效的控制并发读取数据的正确性。
2.事务隔离级别大致可按照如下四大需求定义：可读未提交数据、只能读已提交的数据、提交了的数据也不能读（存在例外）、提交了的数据绝对读不到（因为是串行提交的）
零碎知识点
- 数据库使用两阶段锁：加锁阶段、解锁阶段
- 两类锁：共享锁、排它锁。共享锁可以叠加共享锁，不能叠加排它锁；排它锁不能叠加任何其它的锁
- 查询操作是带共享锁的，在READ UNCOMMITTED、READ COMMITED级别查询完后释放了共享锁，不用等待commit来释放共享锁，REPEATABLE READ、SERIALIZABLE级别会在commit时释放共享锁（可由下面测试结果验证）
| 事务 | 加锁/解锁处理 |
|---|---|
| begin； | |
| insert into test ..... | 加insert对应的锁 |
| update test set... | 加update对应的锁 |
| delete from test .... | 加delete对应的锁 |
| commit; | 事务提交时，同时释放insert、update、delete对应的锁 |
MySQL版本及引擎
SELECT VERSION(); -- 输出：5.7.12-log
测试表结构
CREATE TABLE `user` (
`userId` varchar(20) NOT NULL COMMENT '用户ID',
`userName` varchar(20) DEFAULT NULL COMMENT '用户名称',
PRIMARY KEY (`userId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
事务隔离级别：READ UNCOMMITTED（可读未提交数据）
会话一：
SET session transaction isolation level READ UNCOMMITTED; --
REPEATABLE READ
BEGIN;
SELECT SLEEP(10);
SELECT * FROM `user`; -- 能够查询到会话二插入的数据
COMMIT;
会话二：
SET session transaction isolation level READ UNCOMMITTED; --
READ UNCOMMITTED、REPEATABLE READ
BEGIN;
INSERT `user` VALUES('1', 'username1');
SELECT SLEEP(10);
COMMIT;
事务隔离级别：READ COMMITTED（只能读已提交的数据）
会话一：
SET session transaction isolation level READ COMMITTED;
BEGIN;
SELECT * FROM `user`; -- 查询到以前的数据
SELECT SLEEP(10);
SELECT * FROM `user`; -- 查询到以前的数据（验证查询不到未提交的数据）
SELECT SLEEP(10);
SELECT * FROM `user`; -- 能查询到会话二新增的数据（验证能查询到已提交的数据）
COMMIT;
会话二：
SET session transaction isolation level READ COMMITTED;
BEGIN;
INSERT `user` VALUES('2', 'username2');
SELECT SLEEP(10);
COMMIT;
事务隔离级别：REPEATABLE READ（提交了的数据也不能读（存在例外）
会话一：
SET session transaction isolation level REPEATABLE READ;
BEGIN;
SELECT * FROM `user`; -- 查询到以前的数据（如果去掉该查询，下一个查询在休眠10s后能获取到会话二变更的数据，验证了查询语句在事务隔离级别为REPEATABLE READ时不会立即释放共享锁，而是在commit;时释放共享锁）
SELECT SLEEP(10);
SELECT * FROM `user`; -- 查询到以前的数据（验证即便其它事务已提交也查询不到数据）
SELECT * FROM `user` FOR UPDATE; -- 能查询到会话二提交的数据（验证存在幻读的情况一）
SELECT * FROM `user`; -- 查询到以前的数据
UPDATE `user` SET userName='nihao'; -- 将会话二提交的数据也更新了（验证存在幻读的情况二）
SELECT * FROM `user`; -- 能查询到更新之后的数据
COMMIT;
会话二：
SET session transaction isolation level REPEATABLE READ;
BEGIN;
INSERT `user` VALUES('3', 'username3');
COMMIT;
疑问：
- 问：既然会话一的查询共享锁要到commit;后才释放，为什么会话二没有等待会话一commit;后再执行插入数据？
答：在RR级别是使用乐观锁来实现的，要用FOR UPDATE或lock in share mode才能按照“当前读”的方式读取数据库中最新数据，否则只能读取到快照中的数据，
MVCC在MySQL的InnoDB中的实现
在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下：
- SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
- INSERT时，保存当前事务版本号为行的创建版本号
- DELETE时，保存当前事务版本号为行的删除版本号
- UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行
事务隔离级别：SERIALIZABLE（提交了的数据绝对读不到（因为是串行提交的））
会话一：
SET session transaction isolation level SERIALIZABLE;
BEGIN;
SELECT * FROM `user`; -- 查询到以前的数据（如果去掉该查询，会话二不会等待再执行，验证了查询语句在事务隔离级别为SERIALIZABLE时才不会立即释放共享锁，而是在commit;时释放共享锁）
SELECT SLEEP(10);
SELECT * FROM `user`; -- 查询到以前的数据
COMMIT;
会话二：
SET session transaction isolation level SERIALIZABLE;
BEGIN;（等待会话一执行完毕后才执行）
INSERT `user` VALUES('4', 'username4');
COMMIT;