先看看官方的说法:
semi consistent read

A type of read operation used for UPDATE statements, that is a combination of read committed and consistent read. When an UPDATE statement examines a row that is already locked, InnoDB returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again, and this time InnoDB either locks it or waits for a lock on it. This type of read operation can only happen when the transaction has the read committed isolation level, or when the innodb_locks_unsafe_for_binlog option is enabled.

简单来说，semi-consistent read是read committed与consistent read两者的结合。一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)。

semi-consistent read只会发生在read committed隔离级别或以下，或者是参数innodb_locks_unsafe_for_binlog被设置为true。

semi consistent read作用情形：
1、RC、RU模式下，或者 innodb_locks_unsafe_for_binlog = 1
2、先执行非UPDATE SQL，后执行UPDATE,不会阻塞。如果先执行UPDATE，后执行其他非UPDATE SQL，则还是会加锁
3、只影响有实际存在的行，不存在的行也OK
 

我的理解:
在rc级别或以下级别(ru),或者 innodb_locks_unsafe_for_binlog = 1(RR) 这三种情况下,会发生semi_consistent_read.
因为innodb是行级锁,如果字段没有索引,在加锁时,会上升为表锁.此时,如果s1执行加锁任何操作,s2执行update操作,在s2的update条件中如果在s1中没有行锁,将不会堵塞s2.原理是:s2发起的update,有mysql上层根据update条件判断是否满足,若条件中没有行锁,则mysql会重新发起一次读操作,并在update后加锁;

同理:如果列是有索引存在的.innodb会自动产生的是行锁,所以semi_consistent_read的效能也就没有什么意义..
所以.semi_consistent_read只发生在没有索引的列,或者有全表锁的情况;只要存在update的数据上有行锁的,semi_consistent_read就失效;