在这篇文章里，我将讨论在MySQL 5.7里如何使用InnoDB缓冲池预加载特性。

从MySQL 5.6开始，可以配置MySQL保存InnoDB缓存池的数据，并在启动时加载。在MySQL 5.7后，这是默认行为。在默认配置中，MySQL保存和恢复缓存池的一部分，不再需要任何特殊的配置。我们在Percona Server 5.6中提供了一个类似的功能，所以这个概念已经存在了相当长的时间。

坦率来说，时间已经减少了这个特性的需求。五年前，我们通常是在旋转的硬盘上存储数据库，在数据库正常工作负载下，这些磁盘经常要相当长的时间来预热，这导致在重启之后，好几个小时都是低性能的。

随着固态硬盘的崛起，预热变得很快并且减少了缓冲池中数据的加载。通常，一个系统在10分钟或更少的时间，就能达到其充分预热性能的90%。保存缓冲池内容是一个默认启用的特性，所以它的使用，不需要任何精力。

本篇文章将讨论关于这个功能的一些问题，这些问题可能无法通过字面或文档看出来。

MySQL默认在InnoDB缓冲池（而不是整个缓冲池）中仅保留最频繁访问页的25%。

在多数使用场景下，合理的选择是：保留最有用的数据页，比加载所有的页(很多页可能在后续的工作中并没有访问到)在缓冲池中要更快。

你可以更改innodb_buffer_pool_dump_pct变量的值，如果使用InnoDB作为内存数据库时，想保证所有的数据都在内存驻留，并且可以在不读取磁盘的情况下访问，就要将它设为100。

请注意，这个变量是基于内存中的实际数据量，而不是缓冲池的大小。例如，如果有100GB的缓冲池，但只有10GB的数据，默认只有10GB的25%（即2.5GB）数据保存在内存中（如手册中所述，因为磁盘上只存储页面标识符，而不是完整页内容，所以磁盘上的访问量不会太大）。

MySQL启动并且在缓冲池加载完成前可以通过网络访问。同时在启动之前，大量资源用于尽快从磁盘读取到缓冲池，这个操作可能会影响性能。

如果你有多个MySQL节点（例如使用MySQL复制或Percona XtraDB 集群），则可以考虑在缓冲池加载操作完成后才将他们返回生产环境。您可以通过查看GLOBAL STATUS变量来监视缓冲池加载进度。

缓冲池加载进度：

缓存池加载完成：

另一方面，如果MySQL能提供一个关于节点状态的清晰概念将更好：这与准备以最佳的方式服务于交换往往是不一样的。

InnoDB缓冲池预加载不是非常有效的，至少在快速存储上是这样的。在性能相当好的NVMe存储的测试环境中，在只读负荷下运行时，可以获得超过400MB的/秒的预热速率。InnoDB缓冲池预热速度达到100MB/S，我猜想问题是因为没有开许多并行IO请求的SSD存储运行时需要优化所导致的，但我没有做进一步的研究。

InnoDB缓冲池保存/恢复仅在正常关机状态下保留缓冲池内容。如果服务器崩溃，MySQL仍然会做缓冲池预加载，但仅仅是最近正常关机下的内容信息（存储在ib_buffer_pool文件中），这可能会将时间浪费在与当前工作负荷无关的数据加载上。定期运行操作，可以保证新页可以快速预热，即使是遇到MySQL崩溃的情况。

保留当前缓冲池的列表。

值得注意的是，MySQL崩溃的情况并不是经常碰到的。这个问题在备份时同样存在。MySQL slave从Percona XtraBackup或是LVM快照克隆库，这会导致这些操作性能降低。

希望本文的见解，能帮助你更好地利用这个功能。