针对select for update的原理，在网络上有很多文章都有讲过，具体的用法也有文章进行讲解，其中也不乏一些优秀的文章。但是针对于具体的使用中的表现并没有太多。

本篇博客以select for update与update的执行表现为例，记录实际使用过程中的心得。本篇不讲原理，只讲表现。

阅读必知

• 使用sql命令窗口一，执行select for update，关闭事务的自动提交，模拟在系统中开启了事务，以下简称“事务一”。
• 使用sql命令窗口二，执行update，同样关闭事务的自动提交，模拟在系统中开启了事务。update的操作也可以是事务自动提交的，但是为了更清楚的描述发生了什么，所以也关闭了事务的自动提交，以下简称“事务二”。
• 事务级别：RR——可重复读。

测试过程

第一种情况，select for update执行在“update与update的commit”之间

0. 查看数据的当前状态，使用事务一或事务二均可 ↓

1. 事务一，关闭事务的自动提交 ↓

2. 事务二，关闭事务的自动提交 ↓

3. 事务二，执行update，将status值修改为10 ↓ 可以看到，此时update语句是可以正常执行的，但此时事务二是未提交的。

4. 事务一，执行select，查询当前的status值 ↓ 因为事务二还未提交，所以此时可以看到事务一查询到的status的旧值。

5. 事务一，执行select for update，查询当前的status值 ↓ 因为事务二，还未提交，所以事务一中执行的select for update是被阻塞的，并没有打印查询结果。

6. 事务二，执行commit，将修改提交 ↓ 此时去看事务一的窗口，发现select for update的结果已经正常打印出来，且status的值为update修改的值。

情况一总结：select for update执行在“update与update的commit”之间时，update的事务在未提交之前，会阻塞select for update的执行，只有update的事务提交之后，select for update才能正常返回结果。

情况二，update执行在“select for udpate与select for update的commit”之间

0. 查看数据的当前状态，使用事务一或事务二均可 ↓

1. 事务一，关闭事务的自动提交 ↓

2. 事务二，关闭事务的自动提交 ↓

3. 事务一，执行select for update，但未commit ↓ 结果可以正常返回，但此时已经开启了一个锁，锁定了数据。

4. 事务二，执行update，修改status的值为10 ↓ 因为事务一没有提交，所以事务一持有锁，事务二的update会被阻塞。

5. 事务一，执行commit ↓ 事务一执行commit，此时可以看到事务二的阻塞被解除，修改生效，但此时的update依旧是未commit的 ↓

6. 事务一，执行select，读取到status的旧值：100 ↓ 因为事务一没有commit，所以select查询到的是旧值，即status=100。若此时执行select for update，则进入到了情况一所描述的情况，在此不再展开。

7. 事务二，执行commit ↓

8. 事务一，再次执行select，读到status的值：100 ↓ 因为数据库的事务级别是RR的，所以这个地方读取到的还是100。

9. 事务一，执行一次commit后再执行select，读取status的新值：10 ↓

情况二总结：update执行在“select for update与select for update的commit”之间时，select for update的事务在未提交之前，会阻塞update的执行，只有select for update的事务提交之后，update才能正常返回结果。

总结：select for update执行的是当前读。