MySQL MVCC implementation The question is about the behavior of simultaneous SELECT and UPDATE in MySQL InnoDB table:

We have a relatively large table which we periodically scan reading several fields including a field named, say, LastUpdate. During the scan we update previously scanned rows. Updates are batched and performed in a background thread - using a different connection. It is important to note that we update rows that have already been read.

Three questions:


Will InnoDB will save previous versions of the updated rows since the SELECT is still in progress?
Would using READ-UNCOMMITTED for the SELECT help?
How can I confirm that InnoDB saves or does not save previous versions of the modified rows in its redo-log.
InnoDB always saves the previous version of the row. Everything is copy on write therefore every update is a select -> copy -> write. For how long it is being kept is dependent on 


the open transactions (obviously as long as you have an open transaction that needs to be able to see an old version it cannot be removed)
how busy your server is (purge lag)


Purge behaviour had been improved a lot in the recent version. Look at dev.mysql.com for more info if you're interested. 
I'm not sure what you mean by help. You read first and update next so I don't see too much benefit. You most likely don't want to go below READ-COMMITTED isolation level. That will already eliminate a lot of locking issue (gap locks and next-key locking). 
InnoDB redo log contains every change that happens in the innodb tablespace to be able to recover in case of a system failure. The format is: page pointer offset and the changed bytes. So to answer the explicit use case if the previous version is written to the undo space (which it is) then InnoDB will write that change to the log files too.


I hope this helps!

If you want to look into the details more I always recommend people to play with innodb_ruby that is a very handy tool to look into innodb files and understand the basic principles of operations.