这是我在51CTO博客发表的第一篇博文，如何打造高质量长尾词？

本文共计674个文字，预计阅读时间需要3分钟。

第一段：自我介绍+24年双非软件工程Java方向的一只小菜鸡

第二段：技术分享（MySQL的BinLog日志和RedoLog日志）BinLog：数据库层面的日志，以事务为单位记录SQL语句，属于逻辑日志Re：RedoLog：物理日志，用于保证数据库的持久性

第一段：自我介绍

24届双非本软件工程java方向的一只小菜鸡

第二段：技术分享（MySQL的BinLog日志和RedoLog日志）

BinLog：数据库层面的日志，以事务为单位记录sql语句，属于逻辑日志

RedoLog：储存引擎innoDB的重做日志，记录数据页上的数据更改，属于物理日志，RedoLog，当buffer pool把数据刷到硬盘上时，它会覆盖掉之前的数据。

记录的顺序：当数据更新时，更新数据会先记录到RedoLog日志中，这时RedoLog日志中的日志状态处于prepare状态，当一个事务的操作完成并提交时，MySQL将事务更新到BinLog上，最后将RedoLog改为commit状态。（二阶段提交）

数据库恢复时，认为当BinLog日志有这条事务的记录，即使RedoLog日志是prepare状态，也能够恢复。

数据库恢复：

如果数据库误操作, 如何执行数据恢复?

在回答这个问题之前先了解一个概率：LSN

LSN 是 日志序列号， 为 log sequence number 的缩写，主要用于发生 crash 时对数据进行 recovery。LSN是一个一直递增的整型数字，表示事务写入到日志的字节总量。

LSN 不仅只存在于重做日志中，在每个数据页头部也会有对应的 LSN 号，该 LSN 记录当前页最后一次修改的 LSN 号，用于在 recovery 时对比重做日志 LSN 号决定是否对该页进行恢复数据。

前面说的check point也是由 LSN 号记录的，LSN 号串联起一个事务开始到恢复的过程。

DB宕机后重启，InnoDB 会首先去查看数据页中的LSN的数值。这个值代表数据页被刷新回磁盘的 LSN 的大小。然后再去查看 redo log 的 LSN 的大小。

如果数据页中的 LSN 值大说明数据页领先于 redo log 刷新回磁盘，不需要进行恢复。反之需要从redo log中恢复数据。

如果将 innodb_flush_log_at_trx_commit 和 sync_binlog 参数设置成 1，前者表示每次事务的 redo log 都直接持久化到磁盘，后者表示每次事务的 binlog 都直接持久化到磁盘，可以双重保证 MySQL 异常重启之后的数据不会丢失。

第三段：立一个flag！

9,10月校招上岸！！！