This is an interview question. The general idea is that the database uses a master-slave method. If a transaction involves both reading and writing (read and write operations are multiple times), I know that there may be problems with the database master-slave reading and writing in the same process. (Because writing is to the main library and reading is to the slave library, it is possible that the data just written in the same process has not been synchronized to the slave library in time), but I don’t quite understand the emphasis of this question on whether it will happen in a transaction. What new problems arise, and if any, how are they solved?
The same process you mentioned reading and writing the master-slave library separately should not be a transaction-related issue, right? Because the same transaction does not support cross-databases, as far as I know there is no such thing as a "master-slave transaction". Maybe there is, but it is the implementation of some libraries and has nothing to do with the database. Regardless of whether it is the same process or not, the problem of untimely data synchronization may occur.
There is nothing wrong with a transaction having both reading and writing operations. Think about it, is it reasonable that a transaction can only be all read operations or all write operations? The problem is that in this case, in order to ensure the consistency of data during concurrency, you need to use locks, such as pessimistic locks: to ensure that the data being read by the current transaction will not be read by other transactions, and it must wait until the transaction execution completes the data writing before it can be released. lock, otherwise data confusion will occur. For example: a number 10, two transactions read 10 in parallel without locks, and add 10 before writing. At this time, both transactions write 20, and we hope it should be 30 . I think this interview question should test you on this point.