Mysql – Is it possible that records are changed while a read query is still executing

In an ACID compliant database it is atomic

The write is done in-memory first and flushed to disk (asynchronously) later. Any readers accessing a document will get the in-memory copy straight away, not waiting for the flush to disk to happen (otherwise the database would be disk bound in terms of performance). The reference about locks applies to the in-memory portion, and guarantees the atomicity of the individual operation in-memory - it either happens in full or it does not happen, no in-between states for readers. Hence the two do not conflict with each other, but you should be aware of how they function.

If you are concerned about persistence to disk for a particular write, then I would recommend looking into j:true and w:majority write concerns. The first only returns true once the write is committed to the journal (on disk) and the second only returns true when the write has made it to a majority (2 out of 3, 3 out of 5, etc.) members of a replica set. Please note: both write concerns will incur significant latency (and increased IO for the j:true option) compared to the default, so be sure they are required and that the level of performance is acceptable

Neither option (as the link you provided notes) stops readers from reading the data that has been committed in-memory but not flushed to disk, but j:true will give your application a notification that the write failed in the event that it does not make it to disk and w:majority will let you know if it has been replicated to other members (which would become primary in a failover event). With that knowledge, your application can take the appropriate action (check, retry, other) based on the success/failure of the operation.