MySQL:事务的隔离性

MySQL 数据隔离级别

首先 MySQL 里有四个隔离级别：

• Read uncommttied（可以读取未提交数据）
• Read committed（可以读取已提交数据）
• Repeatable read（可重复读）-
• Serializable（可串行化）。

有3种错误的数据读取：

• 脏读：一个事务中访问到了另外一个事务未提交的数据；
• 不可重复读：一个事务读取同一条记录2次，中间数据有过变更，导致得到的结果不一致
• 幻读：一个事务读取同一个范围的数据2次，中间有插入过数据，导致得到的记录条数不一致：

隔离级别	脏读	幻读	不可重复读
Read uncommttied	√	√	√
Read committed	×	√	√
Repeatable read	×	×	√
Serializable	×	×	×

关于幻读

其实，MySQL的InnoDB引擎默认的RR级别已经通过MVCC自动帮我们解决幻读问题。但是是部分解决。
首先创建一张表：

CREATE TABLE `transaction_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `data` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

开两个窗口：

• case 1：A事务开始后，B事务已提交的数据，在A事务中看不到

# 窗口A
set autocommit =0;
begin;
select * from transaction_test;
结果为：Empty set (0.00 sec)
# 窗口B
insert into transaction_test values (1234, 'cccc');
# 窗口A
select * from transaction_test;
结果为：Empty set (0.00 sec)

可以看到，窗口B提交的数据在窗口A中并没有看到。

• case 1：A事务开始后，B事务已提交的数据，在A事务中同样insert一条数据，会因为主键冲突而失败。在A事务中update或者delete了这条数据，就可以看到B事务写入的这条数据。

# 窗口A
set autocommit =0;
begin;
select * from transaction_test;
结果为：Empty set (0.00 sec)
# 窗口B
insert into transaction_test values (12345, 'cccc');

# 窗口A
mysql> insert into transaction_test values (12345, 'cccc');
ERROR 1062 (23000): Duplicate entry '12345' for key 'PRIMARY'
mysql> select * from transaction_test where id = 12345;
Empty set (0.00 sec)

mysql> update transaction_test set data = '123abc' where id = 12345;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> select * from transaction_test where id = 12345;
+-------+--------+
| id    | data   |
+-------+--------+
| 12345 | 123abc |
+-------+--------+

MySQL官方文档 -- 一致性非阻塞读

The snapshot of the database state applies to SELECT statements within a transaction, not necessarily to DML statements. If you insert or modify some rows and then commit that transaction, a DELETE or UPDATE statement issued from another concurrent REPEATABLE READ transaction could affect those just-committed rows, even though the session could not query them. If a transaction does update or delete rows committed by a different transaction, those changes do become visible to the current transaction.
数据库状态的快照适用于事务中的SELECT语句, 而不一定适用于所有DML语句。 如果您插入或修改某些行, 然后提交该事务, 则从另一个并发REPEATABLE READ事务发出的DELETE或UPDATE语句就可能会影响那些刚刚提交的行, 即使该事务无法查询它们。 如果事务更新或删除由不同事务提交的行, 则这些更改对当前事务变得可见。

MVCC

不少资料将MVCC并发控制中的读操作可以分成两类: 快照读 (snapshot read) 与 当前读 (current read)。

- 快照读, 读取专门的快照 (对于RC，快照（ReadView）会在每个语句中创建。对于RR，快照是在事务启动时创建的)
简单的select操作即可(不需要加锁,如: select ... lock in share mode, select ... for update)
针对的也是select操作

- 当前读, 读取最新版本的记录, 没有快照。 在InnoDB中，当前读取根本不会创建任何快照。
select ... lock in share mode
select ... for update
insert update delete也会导致被影响的行变成当前读，并加锁。
会让如下操作阻塞:    
insert
update
delete

- 在RR级别下, 快照读是通过MVVC(多版本控制)和undo log来实现的, 当前读是通过手动加record lock(记录锁)和gap lock(间隙锁)来实现的。所以从上面的显示来看，如果需要实时显示数据，还是需要通过加锁来实现。这个时候会使用next-key技术来实现。

InnoDB的行锁和表锁

只有通过索引条件检索数据的时候加的是行锁，否则加表锁！假如检索条件没有用到索引，也是加表锁！
也就是说，只要有持有行锁的未提交事务，没有检索条件的加锁语句就会被阻塞。
即便在条件中使用了索引字段,但是否使用索引来检索数据是由MySQL通过判断不同 执行计划的代价来决定的,如果MySQL认为全表扫效率更高,比如对一些很小的表,它就不会使用索引,这种情况下InnoDB将使用表锁,而不是行锁。