1. undo log
The undo log is used to store the value before data modification is modified. It is a logical log. For example, the undo log corresponding to delete sql is an insert sql. There are two functions of undo log, one is for transaction rollback operation to ensure transaction atomicity and partially solve persistence; the other is for MVCC implementation, that is, MVCC implementation depends on undo log.
Simplified process for achieving atomic and durable transactions
Suppose there are two data, A and B, whose values are 1 and 2, respectively.
A. The business begins.
B. Record A=1 to undolog.
C. Modify A=3.
D. Record B=2 to undolog.
E. Modify B=4.
F. Write undolog to disk.
G. Write data to disk.
H. Transaction Commit
There is an implicit precondition here: 'The data is first read into memory, then the data in memory is modified, and finally the data is written back to disk'.
The reason why atomicity and persistence can be guaranteed at the same time is because of the following characteristics:
A. Record the Undo log before updating the data.
B. To ensure durability, data must be written to disk before the transaction is committed. As long as the transaction is successfully committed, the data must be persistent.
C.Undo log
Must be persisted to disk before data. If the system crashes between G and H, the undo log is complete and can be used to roll back the transaction
D. If the system crashes between AF, because the data is not persisted to disk. So the data on disk remains in the state it was in before the transaction started.
Defect: Write data and Undo Log to disk before committing each transaction, which will cause a lot of disk IO, so the performance is very low.
If you can cache data for a period of time, you can reduce IO and improve performance. But this will lose the durability of the transaction. Therefore, another mechanism is introduced to achieve persistence, namely redo log
2. redo log
What is recorded is a backup of the new data. Before the transaction is committed, as long as the Redo Log is persisted, the data does not need to be persisted. When the system crashes, although the data is not persisted, the RedoLog has been persisted. The system can restore all data to the latest state according to the content of RedoLog. Note that both redo log and undo log are sequential IO, while ordinary data writing to disk is random IO, and sequential IO greatly improves efficiency.
-Undo+Redo
business simplification
假设有A、B两个数据，值分别为1,2.
A.事务开始.
B.记录A=1到undolog.
C.修改A=3.
D.记录A=3到redolog.
E.记录B=2到undolog.
F.修改B=4.
G.记录B=4到redolog.
H.将redolog写入磁盘。
I.事务提交
-Undo+Redo
事务的特点
A.为了保证持久性，必须在事务提交前将RedoLog持久化。
B.数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C.RedoLog保证事务的持久性。
D.UndoLog保证事务的原子性。
E.有一个隐含的特点，数据必须要晚于redolog写入持久存储
3. bin log
binlog,即二进制日志,它记录了数据库上的所有改变，并以二进制的形式保存在磁盘中；
它可以用来查看数据库的变更历史、数据库增量备份和恢复、Mysql的复制（主从数据库的复制）。
4. slow log 慢查询日志
MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10s以上的语句。默认情况下，Mysql数据库并不启动慢查询日志，需要我们手动来设置这个参数slow_query_log，当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件，也支持将日志记录写入数据库表。
5. 为什么MySQL有binlog，还有redo log?
这个是因为MySQL体系结构的原因，MySQL是多存储引擎的，不管使用那种存储引擎，都会有binlog，而不一定有redo log，简单的说，binlog是MySQL Server层的，redo log是InnoDB层的。以及redo log是不停的append的，bin log是事务提交后才会触发io写的
http://www.ywnds.com/?p=7892 《binlog 与 redo log 顺序一致性问题》