Re: How does Innodb cleverly avoid read-write conflicts when implementing mvcc?

[Y M]

I think I'm a little confused. Transaction 2 will modify the transaction ID and undo pointer. If step 5 does not happen, only transaction 1 adds a shared lock to the row to avoid the modification of transaction 2.

My above steps were conceived by myself. This is because the information I read tells me that only [Select... Lock in share mode] will explicitly add shared locks to rows. Ordinary select statements before the serial level (without lock in share mode) will not add any locks to rows.

So I will be very puzzled, in the case of not adding a shared lock to the row, will there be no conflict between the transaction id of the transaction 1 accessing the row and the transaction id of the transaction 2 modifying the row?

If the ordinary select statement before the serializable level (without lock in share mode) will also lock the row, can you tell me the relevant information?