13518219792
MySQL
中有六种日志文件，
分别是：重做日志（
redo log
）、回滚日志（
undo log
）、二进制日志（
binlog
）、错误日志（
errorlog
）、慢查询日志（
slow query log
）、一般查询日志（
general log
），中继日志（
relay log
）。
其中重做日志和回滚日志与事务操作
息息相关
，二进制日志也与事务操作有一定的关系，这三种日志，对理解
MySQL
中的事务操作有着重要的意义。
这里简单总结一下这三者具有一定相关性的日志。
重做日志（
redo log
）
十多年的绥中网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都营销网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整绥中建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“绥中网站设计”,“绥中网站推广”以来，每个客户项目都认真落实执行。
作用：
确保事务的持久性。
防止在发生故障的时间点，尚有脏页未写入磁盘，在重启
mysql
服务的时候，根据
redo log
进行重做，从而达到事务的持久性这一特性。
内容：
物理格式的日志，记录的是物理数据页面的修改的信息，其
redo log
是顺序写入
redo log file
的物理文件中去的。
什么时候产生：
事务开始之后就产生
redo log
，
redo log
的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入
redo log
文件中。
什么时候释放：
当对应事务的脏页写入到磁盘之后，
redo log
的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。
对应的物理文件：
默认情况下，对应的物理文件位于数据库的
data
目录下的
ib_logfile1&ib_logfile2
innodb_log_group_home_dir
指定日志文件组所在的路径，默认
./
，表示在数据库的数据目录下。
innodb_log_files_in_group
指定重做日志文件组中文件的数量，默认
2
关于文件的大小和数量，由一下两个参数配置
innodb_log_file_size
重做日志文件的大小。
innodb_mirrored_log_groups
指定了日志镜像文件组的数量，默认
1
其他：
很重要一点，
redo log
是什么时候写盘的？前面说了是在事物开始之后逐步写盘的。
之所以说重做日志是在事务开始之后逐步写入重做日志文件，而不一定是事务提交才写入重做日志缓存，
原因就是，重做日志有一个缓存区
Innodb_log_buffer
，
Innodb_log_buffer
的默认大小为
8M(
这里设置的
16M),Innodb
存储引擎先将重做日志写入
innodb_log_buffer
中。
然后会通过以下三种方式将
innodb
日志缓冲区的日志刷新到磁盘
1
，
Master Thread
每秒一次执行刷新
Innodb_log_buffer
到重做日志文件。
2
，每个事务提交时会将重做日志刷新到重做日志文件。
3
，当重做日志缓存可用空间
少于一半时，重做日志缓存被刷新到重做日志文件
由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，
Innodb_log_buffer
到重做日志文件是
Master Thread
线程的定时任务。
因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。
另外引用《
MySQL
技术内幕
Innodb
存储引擎》（
page37
）上的原话：
即使某个事务还没有提交，
Innodb
存储引擎仍然每秒会将重做日志缓存刷新到重做日志文件。
这一点是必须要知道的，因为这可以很好地解释再大的事务的提交（
commit
）的时间也是很短暂的。
回滚日志（
undo log
）
作用：
保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（
MVCC
），也即非锁定读
内容：
逻辑格式的日志，在执行
undo
的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于
redo log
的。
什么时候产生：
事务开始之前，将当前是的版本生成
undo log
，
undo
也会产生
redo
来保证
undo log
的可靠性
什么时候释放：
当事务提交之后，
undo log
并不能立马被删除，
而是放入待清理的链表，由
purge
线程判断是否由其他事务在使用
undo
段中表的上一个事务之前的版本信息，决定是否可以清理
undo log
的日志空间。
对应的物理文件：
MySQL5.6
之前，
undo
表空间位于共享表空间的回滚段中，共享表空间的默认的名称是
ibdata
，位于数据文件目录中。
MySQL5.6
之后，
undo
表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变
undo log
文件的个数
如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。
关于
MySQL5.7
之后的独立
undo
表空间配置参数如下
innodb_undo_directory = /data/undospace/ --undo
独立表空间的存放目录
innodb_undo_logs = 128 --
回滚段为
128KB
innodb_undo_tablespaces = 4 --
指定有
4
个
undo log
文件
如果
undo
使用的共享表空间，这个共享表空间中又不仅仅是存储了
undo
的信息，共享表空间的默认为与
MySQL
的数据目录下面，其属性由参数
innodb_data_file_path
配置。
Dns8b+B7Z/2gQ8IoEhEij8xJ6sOF/wam1eOsX4Mnm9ySPSdcBuB0ynI+zUpg8HXvAMvXVI1xflyVlxftkGKtn8ZOp/f5ANJWmatiHdIFWvX2T0Ji5tn1l/mpY/Mn1XPiHdLKZvm5tlLPs3G4zn8aau3Qqz9we10czcSKY5nWtf3uLbTSmL36ZEyuRL27ci/q34sjZAHbDZhJjPp9YmKbZ/01ZiuTICZfFbVp7pzQlYD8f5gJybLG51A4P2mxtE2Ad0LNziL+O/n/jv/jZy80GeJUmABEiABEjgJggU3ka+Cc/pJAmQAAmQAAl8E4HOdyN/k93DqsZ6llZkmvHiiaJsppEACZAACVw1Aa5sr7p56RwJkAAJkMAQCPCZ7RBagTaQAAmQAAlcNQEOtlfdvHSOBEiABEhgCAQ42A6hFWgDCZAACZDAVRPgYHvVzUvnSIAESIAEhkCgeLB1vP5eSzgEr2kDCVQRYPxX0WHetRNg/PfSwsWDbS9VUSkJkAAJkAAJ3CYBDra32e70mgRIgARI4BsJpP/OtuLFDFUfCkhflF73In/mF31ogfz0Cz8uHB+M/8IPgTA+BxKftR9iadl/auP/G0elK64q9yECON7Rdyf5dPTzguZbfNk3fR5wLDH+2fdv+VrH+O8l/nkb+YpnUXSNBEiABEhgGAQ42A6jHWgFCZAACZDAFRNIn9lesZN0jQRIgARIgAQuSYAr20vSZ90kQAIkQAI3QYCD7U00M50kARIgARK4JAEOtpekz7pJgARIgARuggAH25toZjpJAiRAAiRwSQIcbC9Jn3WTAAmQAAncBAEOtjfRzHSSBEiABEjgkgQ42F6SPusmARIgARK4CQKFg+3E9Vt9Ys/xglby3ZCXd4UGCHxXqRObgsCHO+lGO9S7SlP9XWntQk/kq/gb/ec5ttay9pF21zJ+d6Dsyns607ZnfT2nuj7i//T4s+P3HD/OkdGxc27718m7fhqX0jcdr8s+eY7H1ypzfvy0jf9rJdqFX7n3QE5c/0rejewcPd9N/HN9/+hOunwnr62/yfuOXd87On2+d3XiHn3D5yY2ZcsMuf2r+IndntO+ffvy//T4+974Er8Dzzme+270OnnHC6zriiofdN0nq9u/Kn6y/aCP8++t//T4EZ/7iv8+eP4knf90MVprHTIjepuP1Olh8xuL9V5nQeftdjtMp9M4XX9RA7X5WpHMjOMqkH6RJM7NfLlit1ppsfT3lwv/bY7YSmx+L2CYmZYrOqrT73gInrVvgMXAlA0CPMf6oy8qxSdV8kX2ZNJkVaGrD4J5lHvYYLZYq2PdBnJi2ZbRU3pq+hApSXSXysQZUbsdsNmEmM81o4PNv8p/s+4yflLXnQs/0O2bxledfV3kN+JbFX+mjxLd2fhty6dKHsB+vcBMQDgPFTj012XybCvlJy4exxssluk1QZWPQtOor1w/KuzX7HV/0n0hiXOTbUX8nHJ9gdG3YOhXNkBfC+IYh4HdKavf0KGAGPoT/0qun6p8Rj4XPwZlHl6GQLLy07OEtjObMvloJpuu7LLl6vJd354Zyww8SFZxztGzZslyHhj5OIp8YJaRVWCQ2qP9L/6t1w/HsVatUl92pVU5s20gX2ybMZtvsLLNcs/qLMvPrsxUeyX8DRtKVu4Rf4N3ln8D/6v4RfGTrpTK/Mj6mz0/V07rKZOvjr8BxVflV1/iflXVb4rki9IK46RCf018CHervxXUWRU/0j7W186s64tcP9LYkraW+tLrD45Q8RyXUcen9f86/ao+g7sdZw3ip5B3vt/aevP5Os75exqbTle2TeYKu9US27jg/isE7myp0vyJi/twZa2WsV1i9SDPfNZY/3rAePOKdOK8xfL3HfyXrH5jJbtf43Xj48kBttoou3h75jTQ/3mHR2PWKsK7VEP9UVv5+hrOLyH8RyOM3gLEa+ZY1xjySLgOn67YbF9k+Xfg/26Vtm9RfGk7LvVr2mf5j58SX1ssZ01bu4yyXr3G+bsVZkuts0J/B/FRZpGsTCuvL2gQ//s1Fr8BX/URWdHOTrpr1qR/mf3Hiu8m16dS55nxHQS+fbD9DqfK6zgg/CzPbZfjwHu7x4fRweTWz1NjpW3lG1d0XsH9F8LDBov4lvR5Sqr4D9z/8xzOSFX5nymaO23Lp618zqDTEj5D4OGX3KxWUzM9YMsGqbs/eqCtUnlh+5vG/69x/IhqhLF2t8otnddUvy7P3x9HoHA38iC92K/xMX7M7CZ28DD+iGaP23eE8ye1ytL2O0/62Z1OGWH+Eu1OVikTFy/zEO9N+nqd/skdxofYFlGudEdPhnXt0e8Yd3pHtDyDCrzI5sbytrbvO9viPZy33GWe4Q/g3/uYf2P/S/h9H4gWNWX8N+Pvx8RXvMtVx21TGoX9t0i4RH/D+BjrziXPL/UGBquakvgptM+4vqA+/mVyHTwDq9kMs9kKeC76Vxkl9TfQb7mRPamLn2x5nn87gcJP7EnQvODVvmVba1rm1lBSPtpI8WlsnrI3EESbdV7xkmyuKspXm60yGwCkCr0hQlWX2UCB3Q676RTTwwarcI7n6UGSMJ3qQTCzQSexueSgQr9sQtKbGCLptK5yG+1NJo3kS0yTZHtzR1wwuUVX3T5b9U+ZnqG3LqXV2Dbm67DzU7n8kev7GIcmf3ujViP/rTZI6zZlS+Mnb1JhiujqOv6hNq+lMRFVnIk/yzcJ7jR+vyO+9KYiC4qxSSdK13GUstfla+UL+i+S+Ey0wAskDvP6zTYGUpZJ/7L0p5vxkk1SUoXFOFOHJR/Zk+iOzSuL/7rrW7JZtKr+wj4c2dhIv6U7Hz+acN3vefFfp5X5QqDzDVJFOpmW53xrTLIbQIbqPzeIMFaHGpvfYRfjv5/4/zm3kTkx+tEEohXBCPO3Yb4I5EfDpfEkQAKDJ1B4G3nwVtNAEiABEiABEvhBBG5sN3JJyxQ8q7FLZp7t2Jn9n9G+/hmzBhIgARLokQBXtj3CpWoSIAESIAESEAJ8Zss4IAESIAESIIGeCXCw7Rkw1ZMACZAACZAAB1vGAAmQAAmQAAn0TICDbc+AqZ4ESIAESIAEigdbx2v5Wj6CJYEfTIDx/4Mbj6a3JsD4b42wSEHxYFtUkmkkQAIkQAIkQAJnEeBgexY2CpEACZAACZBAcwLpv7OteHFC9DJu/QLyrHL9wgfmRy9QJx+bwA+JD8Z//AEAu/Xki8yrmXyDmv37qvt3bfxn44Ln5xDIfYgAjnf03Uk+veCjBd/xYmzW0c+Lscm1hCvjn33/lq91jP9e4p+3kc+ZnlCGBEiABEiABE4gwMH2BFgsSgIkQAIkQALnEEif2Z4jTRkSIAESIAESIIFaAlzZ1iJiARIgARIgARJoR4CDbTt+lCYBEiABEiCBWgIcbGsRsQAJkAAJkAAJtCPAwbYdP0qTAAmQAAmQQC0BDra1iFiABEiABEiABNoR4GDbjh+lSYAESIAESKCWAAfbWkQsQAIkQAIkQALtCOQGW8cLEATBj/7Envjgu5N2ZH6AtOv7yLo5cX3VftKGgeec7EWd/KDjQ97v6rsn+0wBEiABEvgOAsl7ICeufww858h4I5e8M7eD96W6vnd0OtAjbaTaytQlab6btKfjBUfPOcGXGvmfEB8n+2zy43ESO3xv9gn9hnHDuGkQA/+Yo/l+vcBMEpwHM7nxsesHmI+Aw+Y3XvGCNzlJvhoSqdFlojP9RREgSd+tMFtuVbasop6nEIWYLda1dsiqLKozsmGx3icyOm+322E6FaXyl9YfJ9T+JHZKycMBB3xgoW3LfjnDtNvMCwI8xzVFX1SqrTZXwH2cYvd3aaU7D2NsXtO07Z8NHp8cYBvxtAoXnNTJt40PqfJsfrG9SUzI+WGDDe6B1wV0UyufX1xgWx8vBQiYRAIkQAK9EcjPStp89UFWR0GQrrAcL1lduX5gf03IXElN3KMvq+rMDMHx/KM7OW2WKSuwoq8WqZVZkK4sy8plbdDn2fKyijJXkq5v26rqM1aaoqebla1z9Aw/tH05VsI0U78uW/TbWP7M+GjLT/E2YkTxDWzmgLDJpp0WP0VsmEaGjAHGQJsYsFa2XQ3nsrJNVpXbJdRaa+LiPlyl6VLZdonVgzx3XGO9X+Nj7MHBFneyQoasZr/wMP7AMl2gtjZxt5Jvc0Z/+68QuGuucr/+izB4QzDXMrIyjldQ4t9ohNGb2G7+jSFPTnWdZs7Zx5M7jM8WvpxgO34OHsYSEylJtdLOLWC3CA/PGP8C0GHcXI4aayYBErgGAr0MtueC+QrHuJs4GGODVXgP1wHG4de56nqQ22I5Sy/2cDwEvout3EbefyE8bNJbyj3UXq9ylB9kTuLXVr7OwqHzq7Of+SRAAiRwHoHcbuTz1DSQUivXx8zuWVmtfKTP295DjJ8eMP74D9v3EPeP9wjfjcGtQTV9Fina/YtkMNviPZw32AUtE4rYShmsA1nNn/gnA3uBiDyvTJUDztO8gJ8DT3YqF9TbTL6g4oZJ7fgV8Y18sTddOxiPDgg/GxrFYiRAAiTwDQSsla21+QTT6Hapucmn0iC58D0j2noUy8oWpNUM8X4nrF8/4Gdus0p+8vcZYvx8j48/e2D/jvD58YSLplm/aNS3e6NNUJ/J5qkAHmZYwkOgdl9N4cO47Z0YU3QwwtyyX3Snk4HtcqZugae3mUWHvQlr/TdEkOiw84pqLE6LbpU+ZPc+7dcIX4L0NrdsNkvNK1ZlptbIt4sPqagdvyK+ZnwpV+QW+6HbRw8mIh7TAAmQwDkE+D3bc6gNQUZWxQ/vyc7tIZg0BBtkQvDwnk7whmATbSABEiCB77uNTNbdEtgusRlnb8t3W8WP0zZx8TjeJHdSfpz9NJgESOBqCXBle7VNS8dIgARIgASGQoAr26G0BO0gARIgARK4WgIcbK+2aekYCZAACZDAUAhwsB1KS9AOEiABEiCBqyXw/0ZKbqIR53gdAAAAAElFTkSuQmCC">
其他：
undo
是在事务开始之前保存的被修改数据的一个版本，产生
undo
日志的时候，同样会伴随类似于保护事务持久化机制的
redolog
的产生。
默认情况下
undo
文件是保持在共享表空间的，也即
ibdatafile
文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的
undo
信息，全部保存在共享表空间中的。
因此共享表空间可能会变的很大，默认情况下，也就是
undo
日志使用共享表空间的时候，被
“
撑大
”
的共享表空间是不会也不能自动收缩的。
因此，
mysql5.7
之后的
“
独立
undo
表空间
”
的配置就显得很有必要了。
二进制日志（
binlog
）：
作用：
1
，用于复制，在主从复制中，从库利用主库上的
binlog
进行重播，实现主从同步。
2
，用于数据库的基于时间点的还原。
内容：
逻辑格式的日志，可以简单认为就是执行过的事务中的
sql
语句。
但又不完全是
sql
语句这么简单，而是包括了执行的
sql
语句（增删改）反向的信息，
也就意味着
delete
对应着
delete
本身和其反向的
insert
；
update
对应着
update
执行前后的版本的信息；
insert
对应着
delete
和
insert
本身的信息。
在使用
mysqlbinlog
解析
binlog
之后一些都会
真相大白
。
因此可以基于
binlog
做到类似于
oracle
的闪回功能，其实都是依赖于
binlog
中的日志记录。
什么时候产生：
事务提交的时候，一次性将事务中的
sql
语句（一个事物可能对应多个
sql
语句）按照一定的格式记录到
binlog
中。
这里与
redo log
很明显的差异就是
redo log
并不一定是在事务提交的时候刷新到磁盘，
redo log
是在事务开始之后就开始逐步写入磁盘。
因此对于事务的提交，即便是较大的事务，提交（
commit
）都是很快的，但是在开启了
bin_log
的情况下，对于较大事务的提交，可能会变得比较慢一些。
这是因为
binlog
是在事务提交的时候一次性写入的造成的，这些可以通过测试验证。
什么时候释放：
binlog
的默认是保持时间由参数
expire_logs_days
配置，也就是说对于非活动的日志文件，在生成时间超过
expire_logs_days
配置的天数之后，会被自动删除。
对应的物理文件：
配置文件的路径为
log_bin_basename
，
binlog
日志文件按照指定大小，当日志文件达到指定的最大的大小之后，进行滚动更新，生成新的日志文件。
对于每个
binlog
日志文件，通过一个统一的
index
文件来组织。
cDNLxlIf//vy0J+PsP2zB/af8ObTBideU79I1EvX4cayr3hDmoKDMRZwoIIdbUO4MJbwY2PyvvQwSdkvspMLis1iHCznJ0vmIiO9sW314UHFMtJ1eRrzy8Jl3+fsfrL9Ct6rSpbsZQNfYl6+KLO0ov958SGKzuOXx9eMr2AocrvAv+xtFBMRv5MACZDAXQgUbjrLbPy654126i7Y6CEb9owNWOQUcuKfdRXEC4/pow2tPGYYK22Kgdsuid/lkuQHK90ssO5nbzH84PHWGdrAxrS/jld06nRhGxIgARJoA4G/JMP+9etXG2yljSRAAiRAAiTQWQLMsDvreg6cBEiABEigTQQ4YbfJW7SVBEiABEigswQ4YXfW9Rw4CZAACZBAmwhwwm6Tt2grCZAACZBAZwlwwu6s6zlwEiABEiCBNhH4H0G/jmQnBPsTAAAAAElFTkSuQmCC">
其他：
二进制日志的作用之一是还原数据库的，这与
redo log
很类似，很多人混淆过，但是两者有本质的不同
1
，作用不同：
redo log
是保证事务的持久性的，是事务层面的，
binlog
作为还原的功能，是数据库层面的
（当然也可以精确到事务层面的），虽然都有还原的意思，但是其保护数据的层次是不一样的。
2
，内容不同：
redo log
是物理日志，是数据页面的修改之后的物理记录
，
binlog
是逻辑日志，可以简单认为记录的就是
sql
语句
3
，另外，两者日志产生的时间，可以释放的时间，在可释放的情况下清理机制，都是完全不同的。
4
，恢复数据时候的效率，基于物理日志的
redo log
恢复数据的效率要高于语句逻辑日志的
binlog
关于事务提交时，
redo log
和
binlog
的写入顺序，为了保证主从复制时候的主从一致（当然也包括使用
binlog
进行基于时间点还原的情况），是要严格一致的，
MySQL
通过两阶段提交过程来完成事务的一致性的，也即
redo log
和
binlog
的一致性的，理论上是先写
redo log
，再写
binlog
，两个日志都提交成功（刷入磁盘），事务才算真正的完成。
参考：
http://www.cnblogs.com/hustcat/p/3577584.html
总结：
MySQL 中，对于以上三种日志，每一种细化起来都可以够写一个章节的，这里粗略地总结了一下三种日志的一些特点和作用，以帮助理解 MySQL 中的事物以及事物背后的原理。
Mysql 重做日志及与二进制日志的区别
Mysql 重做日志及与二进制日志的区别 （转 http://blog.uouo123.com/post/623.html ）
Mysql 默认情况下会有两个文件： ib_logfile0 和 ib_logfile1 ，这两个文件就是重做日志文件，或者事务日志 。
重做日志的目的： 万一实例或者介质失败，重做日志文件就能派上用场 。
每个 InnoDB 存储引擎至少有一个重做日志文件组，每个文件组下至少有 2 个重做日志文件，如默认的 ib_logfile0 、 ib_logfile1 。 InnoDB 存储引擎先写重做日志文件 1 ，当达到文件的最后时，会切换至重做日志文件 2 ，当重做日志文件 2 也被写满时，会再被切换到重做日志文件 1 中 。
影响重做日志的参数 ：
Innodb_log_file_size 、 innodb_log_files_in_group 、 innodb_log_group_home_dir 影响着重做日志文件的属性 。
