sequence number是什么意思、读音，详解Innodb数据库引擎中的LSN(log sequence number)

老铁们，大家好，相信还有很多朋友对于sequence number是什么意思、读音和详解Innodb数据库引擎中的LSN(log sequence number)的相关问题不太懂，没关系，今天就由我来为大家分享分享sequence number是什么意思、读音以及详解Innodb数据库引擎中的LSN(log sequence number)的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

很多朋友在学mysql数据库或多或少都会碰到LSN这个关键词，那LSN是什么？又有什么作用呢？

LSN称为日志的逻辑序列号(logsequencenumber)，在innodb存储引擎中，lsn占用8个字节。LSN的值会随着日志的写入而逐渐增大。

根据LSN，可以获取到几个有用的信息：

实际上还可以获得很多隐式的信息。

LSN不仅存在于redolog中，还存在于数据页中，在每个数据页的头部FILE_HEADER部分，有一个FIL_PAGE_LSN---记录了该数据页最后被修改的日志序列位置。数据页中还存在FIL_PAGE_FILE_FLUSH_LSN（只存在于共享表空间，独立表空间中该值为0。该值代表了数据页的文件至少被更新到的位置）。通过数据页中的LSN值和redolog中的LSN值比较，如果页中的LSN值小于redolog中LSN值，则表示数据丢失了一部分，这时候可以通过redolog的记录来恢复到redolog中记录的LSN值时的状态。

redolog的LSN信息可以通过showengineinnodbstatus命令来查看。MySQL5.5版本的show结果中只有3条记录，没有pagesflushedupto。

mysql>showengineinnodbstatus\\G;\n

其中：

(1).首先修改内存中的数据页，并在数据页中记录LSN，暂且称之为data_in_buffer_lsn；

(2).并且在修改数据页的同时(几乎是同时)向redologinbuffer中写入redolog，并记录下对应的LSN，暂且称之为redo_log_in_buffer_lsn；

(3).写完buffer中的日志后，当触发了日志刷盘的几种规则时，会向redologfileondisk刷入重做日志，并在该文件中记下对应的LSN，暂且称之为redo_log_on_disk_lsn；

(4).数据页不可能永远只停留在内存中，在某些情况下，会触发checkpoint来将内存中的脏页(数据脏页和日志脏页)刷到磁盘，所以会在本次checkpoint脏页刷盘结束时，在redolog中记录checkpoint的LSN位置，暂且称之为checkpoint_lsn。

(5).要记录checkpoint所在位置很快，只需简单的设置一个标志即可，但是刷数据页并不一定很快，例如这一次checkpoint要刷入的数据页非常多。也就是说要刷入所有的数据页需要一定的时间来完成，中途刷入的每个数据页都会记下当前页所在的LSN，暂且称之为data_page_on_disk_lsn。

上图中，从上到下的横线分别代表：时间轴、buffer中数据页中记录的LSN(data_in_buffer_lsn)、磁盘中数据页中记录的LSN(data_page_on_disk_lsn)、buffer中重做日志记录的LSN(redo_log_in_buffer_lsn)、磁盘中重做日志文件中记录的LSN(redo_log_on_disk_lsn)以及检查点记录的LSN(checkpoint_lsn)。

假设在最初时(12:00:00)所有的日志页和数据页都完成了刷盘，也记录好了检查点的LSN，这时它们的LSN都是完全一致的。

假设此时开启了一个事务，并立刻执行了一个update操作，执行完成后，buffer中的数据页和redolog都记录好了更新后的LSN值，假设为110。这时候如果执行showengineinnodbstatus查看各LSN的值，即图中①处的位置状态，结果会是：

logsequencenumber(110)>logflushedupto(100)=pagesflushedupto=lastcheckpointat

之后又执行了一个delete语句，LSN增长到150。等到12:00:01时，触发redolog刷盘的规则(其中有一个规则是innodb_flush_log_at_timeout控制的默认日志刷盘频率为1秒)，这时redologfileondisk中的LSN会更新到和redologinbuffer的LSN一样，所以都等于150，这时showengineinnodbstatus，即图中②的位置，结果将会是：

logsequencenumber(150)=logflushedupto>pagesflushedupto(100)=lastcheckpointat

再之后，执行了一个update语句，缓存中的LSN将增长到300，即图中③的位置。

假设随后检查点出现，即图中④的位置，正如前面所说，检查点会触发数据页和日志页刷盘，但需要一定的时间来完成，所以在数据页刷盘还未完成时，检查点的LSN还是上一次检查点的LSN，但此时磁盘上数据页和日志页的LSN已经增长了，即：

logsequencenumber>logflushedupto和pagesflushedupto>lastcheckpointat

但是logflushedupto和pagesflushedupto的大小无法确定，因为日志刷盘可能快于数据刷盘，也可能等于，还可能是慢于。但是checkpoint机制有保护数据刷盘速度是慢于日志刷盘的：当数据刷盘速度超过日志刷盘时，将会暂时停止数据刷盘，等待日志刷盘进度超过数据刷盘。

等到数据页和日志页刷盘完毕，即到了位置⑤的时候，所有的LSN都等于300。

随着时间的推移到了12:00:02，即图中位置⑥，又触发了日志刷盘的规则，但此时buffer中的日志LSN和磁盘中的日志LSN是一致的，所以不执行日志刷盘，即此时showengineinnodbstatus时各种lsn都相等。

随后执行了一个insert语句，假设buffer中的LSN增长到了800，即图中位置⑦。此时各种LSN的大小和位置①时一样。

随后执行了提交动作，即位置⑧。默认情况下，提交动作会触发日志刷盘，但不会触发数据刷盘，所以showengineinnodbstatus的结果是：

logsequencenumber=logflushedupto>pagesflushedupto=lastcheckpointat

最后随着时间的推移，检查点再次出现，即图中位置⑨。但是这次检查点不会触发日志刷盘，因为日志的LSN在检查点出现之前已经同步了。假设这次数据刷盘速度极快，快到一瞬间内完成而无法捕捉到状态的变化，这时showengineinnodbstatus的结果将是各种LSN相等。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！