这是我写的第18封信，我们会遇到很多事情，很多事情都来妨碍我们的计划，我们的计划也要跟得上变化，没有什么计划应该是一成不变的。比方说，我想每天早上8点到8点30之间来更新，但这周就拼拼需要早点去上班，8点就出门赶地铁去了。
MySQL当前读
有一个场景，我就有疑惑过：既然MySQL在事务的过程中实现了多版本并发控制，能读取的数据就应该是小于等于当前的数据版本，那为什么写的场景能够把数据写正确呢？
image.png
假设id 是1的记录score初始值为0，左边的事务执行完成之后，score的结果是5而不是2。
如果只从多版本并发控制上来说，有点摸不着头脑。
如果我这样理解，多版本是用来解决读一致问题的，对于写的场景，多版本并不能控制。但其实写的场景里也包含读的部分，MySQL要更新一行记录，总得先把记录读取出来，更新完成之后，再写入内存。
从单条语句上来分析，MySQL 写就是写，它是一个完整的事务，而不会因为它内部有读的逻辑，而拆分成两个事务。
这就是写场景的当前读，写场景读取的数据一定是最新版本的数据。所以，例子中左边的事务其实会阻塞，直到右边的事务执行完毕。
在对查询语句加锁的访问，比如，for update ，触发的也是当前读。当前读就可能会有阻塞等待的情况。
