MySQL:事务的隔离性 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 = 'https://www.it610.com/article/123abc' where id = 12345; Query OK, 1 row affected (0.00 sec) Rows matched: 1Changed: 1Warnings: 0 mysql> select * from transaction_test where id = 12345; +-------+--------+ | id| data| +-------+--------+ | 12345 | 123abc | +-------+--------+

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

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