FOR UPDATE：锁定读和普通一致性读的区别

做的事：A锁住一行，B和C分别用两种方式去碰它

A用SELECT ... FOR UPDATE锁住一行不提交，B用普通SELECT读它，C用UPDATE改它。

操作A: START TRANSACTION A: SELECT v FROM t4 WHERE id=1 FOR UPDATE → 锁住id=1这一行，v=100 B: SELECT v FROM t4 WHERE id=1 （普通一致性读，不加锁） C: UPDATE t4 SET v=999 WHERE id=1 （需要获取写锁） 1.5秒后 A: COMMIT

验证：B完全不受影响，C被卡住1.5秒

同样是访问A锁住的那一行，B和C的遭遇完全不同。

结果B的普通SELECT：耗时 0.0001 秒，立刻拿到 v=100 C的UPDATE：卡住，在A提交前一直等待 1.5秒后Acommit C的UPDATE完成，总耗时 1.5029 秒（几乎正好等于A的提交延迟）

B的普通SELECT完全没有被A的 FOR UPDATE 锁影响，0.0001秒瞬间返回——这就是"一致性读"：普通SELECT走的是MVCC快照读，不需要获取任何锁，也就不会被别的事务持有的锁挡住。而C的UPDATE被阻塞了整整1.5秒，直到A提交才完成——因为UPDATE要获取这一行的排他锁，而A的 FOR UPDATE 已经持有了这把锁。

分步演示：一致性读与锁定读的分界线

每一步都是本文上面用三个MySQL连接跑出来的原始结果。