一条更新语句是如何执行的
执行 update tbl set c=c+1 where id =2
redo log 和 binlog
- redo log
redolog 是InnoDB特有的
有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。 - binlog
是service层的，任何引擎都可用 - 如何保证两个日志一直性？两阶段提交
1 prepare阶段 2 写binlog 3 commit
当在2之前崩溃时
重启恢复：后发现没有commit，回滚。备份恢复：没有binlog 。
一致
当在3之前崩溃
重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog. 一致
如果在数据库crash(异常重启)后，需要通过检查binlog来确认redo log中处于prepare的事务是否需要commit - 如果只有redo log
1)redolog只有InnoDB有，别的引擎没有.
2)redolog是循环写的，不持久保存，binlog的“归档”这个功能，redolog是不具备的. - 如果只有binlog
历史上的原因是，这个是一开始就这么设计的，所以不能只依赖binlog.
操作上的原因是，binlog是可以关的，你如果有权限，可以set sql_log_bin=0关掉本线程的binlog日志。 所以只依赖binlog来恢复就靠不住. - redo是物理的，binlog是逻辑的
备份时间周期的长短，感觉有2个方便
首先，是恢复数据丢失的时间，既然需要恢复，肯定是数据丢失了。如果一天一备份的话，只要找到这天的全备，加入这天某段时间的binlog来恢复，如果一周一备份，假设是周一，而你要恢复的数据是周日某个时间点，那就，需要全备+周一到周日某个时间点的全部binlog用来恢复，时间相比前者需要增加很多；看业务能忍受的程度
其次，是数据库丢失，如果一周一备份的话，需要确保整个一周的binlog都完好无损，否则将无法恢复；而一天一备，只要保证这天的binlog都完好无损；当然这个可以通过校验，或者冗余等技术来实现，相比之下，上面那点更重要