在InnoDBMySQL中刷新到磁盘之前，脏的数据库页面通常在内存中保留多长时间？

我所说的数据库页面是：

https://dev.mysql.com/doc/internals/zh-CN/innodb-page-structure.html

现在，当我们对它发出查询时，这些页面将被加载到内存中，并且仅在此处进行更改并被标记为脏

我不确定这取决于操作系统还是数据库，但是我的问题是这些页面通常在内存中停留多长时间？

可以说，我们有一个用于高负载Web服务器的数据库，它的流量很大，缓冲区大小大约为1gb左右（不确定通常有多少个数据库服务器），现在这1gb中有多少是脏页？

如果没有备用电源而断电，那么对这些脏页的所有更改都会丢失正确吗？（基本上，我想知道是否发生断电，如果没有备用电源，并且发生大量插入和查询，那么内存中脏数据将丢失的估计百分比是多少？）

例如，这些脏页是否有可能在繁忙的服务器上停留超过12或24小时？

编辑：通过脏页面，我的意思是页面在内存中被修改，例如其中的一行被更新或删除

这些页面通常在内存中停留多长时间？

这是可变的。InnoDB有一个后台线程将脏页刷新到磁盘。它会刷新少量的页面，然后在1秒后再次刷新。

因此，如果您在短时间内进行大量更新，则会使许多页面变脏。然后，冲洗线程将逐渐将它们冲洗到磁盘上。这个想法是，这有助于随着时间的推移扩展工作，因此突然的更新高峰不会使您的磁盘不堪重负。

但这意味着“这些页面在内存中脏了多久”可能会有很大不同。我认为在典型情况下，这将在几分钟内完成。

不同版本的MySQL以不同的方式刷新。几年前，主后台线程每1秒刷新固定数量的页面。然后他们提出了自适应冲洗功能，因此如果它检测到您进行了很多更改，它将自动提高冲洗速率。然后，他们提出了一个称为页面清洁器的专用线程。我认为甚至可以将MySQL配置为运行多个页面清理程序线程，但这对于大多数应用程序不是必需的。

您可能也对我对以下这些问题的回答感兴趣：

如何计算页面清洁器线程每秒执行的工作量？

如何解决mysql警告：“ InnoDB：page_cleaner：1000ms的预期循环用了XXXms。设置可能不是最佳的”？

可以说...缓冲区大小大约为1gb左右（不确定数据库服务器通常有多少个）

确实有所不同，取决于应用程序。开箱即用的默认innodb缓冲池大小为128MB，但这对于大多数应用程序来说太小了，除非它是一个测试实例。

在我公司，我们尝试将缓冲池保持在磁盘上至少10％的数据大小。一些应用程序需要更多。我们最常用的大小是24GB，但是最小的大小是1GB，最大的大小是200GB。我们管理着4,000多个生产MySQL实例。

这些1gb中有多少可能是脏页？

从理论上讲，所有这些。MySQL有一个config变量调用innodb_max_dirty_pages_pct，如果您有太多的话，您可能会认为它会阻止任何进一步的脏页。但事实并非如此。即使缓冲池比该变量脏（百分比），您仍然可以修改更多页面。

该变量的实际作用是，如果缓冲池超过了脏页的百分比，则刷新脏页的速率会增加（IIRC，它会使每个周期刷新的页数增加一倍），直到该数目降至该百分比以下再次阈值。

如果没有备用电源而断电，那么对这些脏页的所有更改都会丢失正确吗？

是的，但是您不会丢失更改，因为可以从InnoDB重做日志中重建它们-这两个文件iblogfile_0，iblogfile_1您可能已经在数据目录中看到了。提交期间，任何创建脏页的事务都必须记录在重做日志中。

如果您断电（或以其他方式重新启动mysqld进程），InnoDB要做的第一件事是扫描重做日志以检查记录的每个更改是否在崩溃之前被刷新，否则，请加载原始页面并重新应用日志中的更改以再次创建脏页。这就是InnoDB所谓的崩溃恢复。

您可以观看这种情况。当您kill -9使用mysqld进程时，在MySQL Server的测试实例上尾注错误日志。mysqld_safe将重新启动mysqld进程，这将在执行崩溃恢复时向错误日志中注入大量信息。

如果只有少量脏页要恢复，这将非常快，也许只有几秒钟。如果缓冲池很大，并且有很多脏页，则需要更长的时间。在崩溃恢复完成之前，MySQL服务器尚未完全启动，并且无法建立新的客户端连接。在观察崩溃恢复的进度时，这已经引起了许多MySQL DBA的焦虑。无法预测崩溃后需要多长时间。

由于恢复崩溃需要重做日志，因此，如果重做日志已满，MySQL 必须刷新一些脏页。它不会清除脏页，也无法从重做日志中恢复它们。如果发生这种情况，您实际上会看到InnoDB暂停了写操作，直到它可以对最旧的脏页执行“紧急刷新”。对于MySQL来说，这曾经是一个问题，但是随着自适应刷新和页面清理器的改进，它可以更好地跟上更改的步伐。您必须拥有非常多的写入操作，并且重做日志的大小要小，以便在InnoDB进行同步刷新时遇到硬停止。

这是一个有关冲洗的好博客：https : //www.percona.com/blog/2011/04/04/innodb-flushing-theory-and-solutions/

PS：为了对MyISAM进行强制性的抨击，我将指出MyISAM没有重做日志，没有崩溃恢复，并且在写入其数据文件期间依赖于主机OS文件缓冲区。如果主机电源出现故障，而文件缓冲区中有未决的写操作尚未写入磁盘，则您将丢失它们。MyISAM对ACID的耐用性属性没有任何实际支持。

发表您的评论：

重做日志回收时，页面可能会被刷新。也就是说，如果您有2个48MB的重做日志文件（默认大小），并且向其中写入了足够的事务以完全循环通过它并从头开始，则在此期间缓冲池中变脏的任何页面都需要被冲洗。如果重做日志中的相应事务被新事务覆盖，则页面不能在BP中保持脏状态。

据我了解，脏页几乎不可能在不刷新12-24小时的情况下保持在缓冲池中。

我可能在猜测，可能的例外是给定页面在刷新之前一次又一次地更新。因此，它长期以来一直是最近的脏页。同样，我不确定重做日志回收时是否能克服刷新页面的需要。

无论如何，我认为这种可能性很小。

另外，我不确定您所说的取证是什么意思。没有直接方法可以从缓冲池检查页面版本。要从InnoDB获取有关最近更改的信息，您需要检查undo段以查找页面的先前版本，并将它们与重做日志条目相关联。脏页及其以前的版本都可以在缓冲池中或磁盘上。没有命令或API或任何数据结构可以进行任何这种关联。因此，您将手动转储磁盘映像和内存映像，并手动跟随指针。

跟踪数据更改的一种简单得多的方法是检查二进制日志中的更改流。这独立于InnoDB。