日志的记录和维护是数据库中相当重要的内容，写这篇文章和后面几篇文章作为学习官网文档的笔记。MariaDB数据库日志可分为二进制日志、查询日志、错误日志、myISAM表日志、relay日志和撤销日志（undo log）。
MariaDB（mysql）的undo log 保存数据被InnoDB事务修改前的版本，用于数据恢复或者提供给“一致读consistent read”级别的事务读取，具体细节如下：
1.在某行数据被修改前，首先复制数据到undo log中，表中的每行数据包含一个指针指向undo log中最近的版本，redo log中的每行数据则包含一个指向前一个版本的指针（如果有的话），这样每行被修改的数据就形成了一个记录变更的“历史链history chain”,或者称之为变更集吧。
2.MariaDB中的每一个事物都运行在一定的隔离级别上，这个隔离级别isolation level 决定了怎样创建记录的“视图view”，对于READ UNCOMMITTED通常使用记录当前的版本（不管是否提交，即“脏读dirty reads”）。其它的事务隔离级别的视图则在redo log中查找最后一次提交的版本，READ COMMITTED针对每个表使用不同的视图，REPEATABLE READ可重复度和SERIALIZABLE则针对所有的表使用统一的视图。
3.存在一个全局的变更集（history chain），当有事务提交时，则将该记录版本添加到这个变更集中，这个变更集中的记录是按照事务提交的先后顺序保存的。
4.MariaDB的purge thread会删掉现有视图（view）不再需要的redo log中的记录。
在MariaDB中运行长事务会有哪些问题呢，从redo log工作的方式来考虑，首先的问题就是会造成redo log体积膨胀，因为较长的事务需要保存更多的版本历史，另一个问题是，如果事务需要读取很早之前的版本，就会造成性能影响。虽然只读的事务不会向redo log写记录，但是这些事务会阻止purge thread线程清除redo log，也会造成redo log臃肿。还有一个问题是，使用长事务更容易发生死锁，当然死锁和redo log没有关系。
和undo log相关的一些系统变量配置：
1.MariaDB的undo log通常是物理磁盘上的系统表空间的一部分，在10.0以后的版本中，可以使用 innodb_undo_directory 和 innodb_undo_tablespaces系统变量来将undo log保存到指定的设备位置。
2.innodb_undo_logs系统变量用于确定每个事物可用的最多回滚段数（undo log中的关于insert或者update操作的部分就是回滚段）。
3.innodb_avaliable_undo_logs状态变量保存InnoDB undo log中总的可用回滚段数。
4.innodb_flush_log_at_trx_commit决定了事物写入（flush）到undo log的频率，调整这个参数可以在速度和稳定性方面取得平衡（想必事物太频繁的flush undo log会造成性能低下）， Binlog group commit and innodb_flush_log_at_trx_commit中有更详细的说明。
