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 |
+-------+--------+
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将使用表锁,而不是行锁。
