面试被吊打系列：气得我直接把简历上的精通数据库给删掉了
隔离性（Isolation）：多个事务并发访问时，事务之间是隔离的。
持久性（Durability）：事务完成后，事务对数据库的操作被保存在了数据库，不能回滚。
面试官：嗯，答得很对。那你说说事务有哪几种隔离级别呢？
小张：事务隔离级别从高到低有四种隔离级别，分别是：串行化（SERIALIZABLE） 、可重复读（REPEATABLE READ）、读提交（READ COMMITTED）、读未提交（READ UNCOMMITTED）。
面试官：嗯嗯，那你能说说这四种隔离级别分别会造成什么问题吗？
（小张窃喜，我就知道你要这么问，还好我平时关注了 ‘ JAVA 日知录 ’ 的公众号）
小张：好的，面试官。
如果数据库采用读未提交（READ UNCOMMITTED）这种隔离级别，会造成脏读。事务还没提交别人就能看到，这样就不能保证你读取到的数据是最终的数据，万一别人把事务回滚了，那就出现了脏数据问题。
读提交（READ COMMITTED）是指一个事务只能读取到其他事务已经提交了的数据，这样就不会出现脏读的问题，但是它会带来不可重复读的问题。比如 A 事务 将一个人的姓名从张三改成李四，B 事务在 A 事务提交之前读取到的是张三，但是在 A 事务提交之后就变成了李四。
可重复读（REPEATABLE READ）：可重复读是为了解决 READ COMMITTED 带来的不可重复读问题，指的是事务不会读取到其他事务对已有数据的修改，即使数据已经提交了。也就是说事务开始读取到的是什么，在事务提交之前的任意时刻，这些数据都一样。虽然解决了不可重复读问题，但是他又会带来幻读的问题。比如 A 事务将张三修改成李四，B 事务再插入一个名叫李四的用户，此时事务 A 再查找名叫李四的用户会发现多了一条，出现了 2 个李四，这就是幻读。
串行化（SERIALIZABLE）：解决了上面出现的所有问题，但是它效率最差，它将事务的执行变成顺序执行了。
面试官：回答得不错，那你知道 MySQL 的默认隔离级别是什么吗？
小张：Mysql 默认的隔离级别是 REPEATABLE READ，Oracle 则采用的是 READ COMMITTED。
面试官：但是我们使用 MySQL 的时候并没有出现幻读啊，怎么解决的？
小张擦了擦汗，开始有点紧张了：额，InnoDB 主要是利用锁来解决幻读问题的。
面试官：对，是采用了锁，那么具体怎么实现的呢？
小张：我...我突然有点事，我先回去了。
面试官：要了解 InnoDB 怎么解决幻读得先知道 InnoDB 有哪几种锁。
Record Lock：单个行记录上的锁
Gap Lock：间隙锁，锁定一个范围，而非记
录本身，遵循左开右闭原则
Next-Key Lock：结合 Gap Lock 和 Record Lock，锁定一个范围，并且锁定记录本身。主要解决的问题是 REPEATABLE READ 隔离级别下的幻读。
注意，如果走唯一索引，那么 Next-Key Lock 会降级为 Record Lock，即仅锁住索引本身，而不是范围。也就是说 Next-Key Lock 前置条件为事务隔离级别为 RR 且查询的索引走的非唯一索引、主键索引。
下面我们通过具体的例子来模拟上面出现的幻读问题：
CREATE TABLE T (id int ,name varchar(50),f_id int,PRIMARY KEY (id), KEY(f_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8
insert into T SELECT 1,'张三',10;
insert into T SELECT 2,'李四',30;
InnoDB 在数据库中会为索引维护一套 B+树，用来快速定位行记录。B+索引树是有序的，所以会把这张表的索引分割成几个区间。
事务 A 执行如下语句，需要将张三修改成李四。
select * from t;
update t set name = '李四' where f_id = 10;
这时 SQL 语句走非唯一索引，因此使用 Next-Key Lock 加锁，不仅会给 f_10=10 的行加上行锁，而且还会给这条记录的两边添加上间隙锁，即(-∞,10]、(10,30]这 2 个区间都加了间隙锁。
评论