Ⅰ、看一个幻读的模型
表a中有4条记录1,3,5,7,开两个session
session1：begin; delete <= 7 ;
session2：begin; insert a values(2); commit;
session1：commit;
这个模型在rc的情况下,这是没问题的,只是加记录锁,不会锁范围,插入2是可以的。最后a上就剩2这个记录
那binlog里面记录的内容就有讲究了,假设是statment格式的binlog
insert 2;
delete <= 7;
这时候数据库做同步，从库上就gg了,一个事务所做的修改对另一个事务不可见,好似串行
这就是不符合隔离性的要求,并行执行和串行执行的结果不一样
row格式的binlog是下面这样记录的：
insert 2;
delete 1,delete 3, delete 5, delete 7
这样2就还在
所以,一定要用row,row记录的是一条一条记录,而不是简单的sql.所以说rc的情况下设置为row,主从还是可以保持一致的
5.1版本才支持row,主从复制从3.23就开始支持,中间差了4.0,4.1,5.0三个版本,最早为什么innodb要支持这样的锁,也有部分原因是当时的MySQL的复制不用Next-key Lock,就是根本不可用的,因为innodb可以并行的,有并发问题,不像其他存储引擎有表锁
tips：
- binlog_format这个参数5.7之前默认statement，之后默认row
- 其实不用我们担心,在事务隔离级别为rc的情况下,binlog_format随便你怎么设MySQL都会给你记为row的,不信可以试试
Ⅱ、如何判断一条记录的可见性
先讲两句题外话，这个判断的是根据事务id来做的,每条记录有rowid、txid、rowpointer,后面才接用户的列
txid是6个字节的,其实每个事务分配的,而且是全局自增的,在共享表空间的某个位置存放着当前max的txid,所以每开启一个事务都会分配一个txid
2.1 具体怎么判断？
①当前活跃事务列表,里面记录着当前正在执行未提交的事务
begin;
xxx 随便什么语句
这时候产生一个read_view的内存对象,现在在mysql里面完全看不到,能看到的就是下面这个,有多少个read_view开着,我们通过这个read_view来判断记录的可见性
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=23137, Main thread ID=139830599059200, state: sleeping
Number of rows inserted 116, updated 27, deleted 0, read 130
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
这个read_view就是把事务开始的时候事务活跃列表拷贝一份出来,这时候会拿到很多个事务id,只要你的记录对应的事务id在这个活跃列表中,意味着这个记录不可见,因为这条记录在select这个事务开启的时候还没提交,所以该记录的事务id对新产生的事务是不可见的
②read_view在rc和rr中的区别
rr中read_view只产生一次,rc中每执行一条sql语句就会创建一个read_view
原因：rc可以读到已经提交的事务的记录,第二次执行还要检查事务活跃列表,如果提交了这条记录就可见,而rr实现了可重复读
如果一个事务执行时间很长,它插入了一条记录,是否可见？就看创建read_view的时候这个tx_id有没有在活跃列表中,如果不在就意味着不可见,那就不会删掉了。
rr的好处,read_view只创建一次,rc要创建n次
如果事务活跃列表很长的话,每次拷贝的时候要锁住所有活跃事务(latch,5.5版本叫kernel_mutex,这个锁很大),需要时间还是挺长的,但5.6,5.7都开始做优化了(把大锁拆分了)
所以,一个事务中有很多条操作,而且全是select操作(随机主键值查询),这时候rr性能更好,没有insert所以不会有gap锁导致的并发插入影响,这种情况太少了,所以我们还是选择rc
2.2 read_view什么时候分配？
begin的时候还是执行第一条sql的时候？
测一把便知
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)
mysql> desc l;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| a | int(11) | NO | PRI | NULL | |
+-------+---------+------+-----+---------+-------+
1 row in set (0.00 sec)
mysql> select * from l;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
+---+
3 rows in set (0.00 sec)
测试一：
session1：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
session2：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into l values (4);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from l;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
+---+
4 rows in set (0.00 sec)
session1：
mysql> select * from l;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
+---+
4 rows in set (0.00 sec)
测试二：
session1:
mysql>
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from l;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
+---+
3 rows in set (0.00 sec)
session2:
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into l values (4);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from l;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
+---+
4 rows in set (0.00 sec)
session1：
mysql> select * from l;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
+---+
3 rows in set (0.00 sec)
按道理如果事务隔离级别为rr,那一个事务提交了,对另一个事务不可见,解决不可重复读,这样看测试二是合理的,
那为什么,测试二session1一开始select了一把,session2里面事务提交了,session1就不可见,而测试一session1一开始没有select,后面再select就可见了？这是重复读的体现吗？
原因：rr隔离级别的时,事务中有select时会创建一个read_view,而且一个事务只创建一次,所以测试一的时候,最后session1 select的时候才创建了read_view,发现session2的事务中相关记录已经commit了,不在事务活跃列表中,所以读到了这条记录,而测试二,session1 开启事务,第一个select的时候就创建了read_view,这时候session2里面的事务还没开启,第二个select的时候用的还是原来的rv,这样就不可见了
tips：
如果希望begin的时候就创建read_view
必须用start transaction with consistent snapshot; 结合rr用,因为rc时候,事务中每执行一个sql就会创建read_view
session1：
start transaction with consistent snapshot; 创建了rv
session2:
begin;
insert aaa;
commit;
session1:
select aaa;查不到,创建rv的时候,session2中的事务还不存在
如果rc的话能读到aaa,因为第三步session1里执行select又会创建一个rv,会发现aaa这个记录已经提交了,就能看到了