InnoDB：page_cleaner：1000毫秒的预期循环耗时4013毫秒。设置可能不是最佳的。（在这段时间内刷新为1438，逐出为0）。
这个问题是典型的MySQL实例，其中您对数据库的更改率很高。通过运行5GB导入，您可以快速创建脏页。创建脏页时，页面清除器线程负责将脏页从内存复制到磁盘。
就您而言，我假设您并非一直都导入5GB。因此，这是非常高的数据负载率，而且是暂时的。您可能会忽略警告，因为InnoDB会逐渐赶上。
这是导致此警告的内部原因的详细说明。
每秒一次，页面清理程序扫描缓冲池中是否有脏页，以将其从缓冲池刷新到磁盘。您看到的警告表明它有很多脏页要刷新，并且需要花费4秒多的时间将一批脏页刷新到磁盘上，而这应该在1秒内完成。换句话说，它咬的东西超过了它的咀嚼能力。
您通过将它
innodb_lru_scan_depth从1024 减少到256
进行了调整。这减少了页面清洁器线程在每秒一次的循环中搜索脏页到缓冲池的距离。您要求它咬一点。
请注意，如果您有许多缓冲池实例，它将导致刷新工作更多。它
innodb_lru_scan_depth减少了每个缓冲池实例的工作量。因此，您可能在不减小扫描深度的情况下无意中通过增加了缓冲池的数量而导致了该瓶颈。
的文档
innodb_lru_scan_depth说：“小于默认设置通常适用于大多数工作负载。” 听起来他们给此选项的默认值太高。
您可以使用
innodb_io_capacity和
innodb_io_capacity_max选项来限制后台冲洗使用的IOPS
。第一个选项是InnoDB将请求的I /
O吞吐量的软限制。但是这个限制是灵活的。如果刷新落后于新的脏页创建速度，则InnoDB将动态增加刷新率，使其超过此限制。第二个选项对InnoDB可能增加刷新率的范围进行了更严格的限制。
如果刷新率能跟上创建新脏页的平均率，那么您会没事的。但是，如果您始终以比刷新它们快的速度创建脏页，则最终您的缓冲池将充满脏页，直到脏页超出
innodb_max_dirty_page_pct缓冲池为止。此时，刷新率将自动增加，并可能再次导致page_cleaner发送警告。
另一个解决方案是将MySQL放在具有更快磁盘的服务器上。您需要一个I / O系统，该系统可以处理页面刷新所需的吞吐量。
如果您始终在平均流量下看到此警告，则可能是您尝试在此MySQL服务器上执行太多写查询。现在可能是横向扩展并将写入分成多个MySQL实例的时候了，每个实例都有自己的磁盘系统。
了解有关页面清洁器的更多信息：
- 在InnoDB中引入page_cleaner线程（归档副本）
- MySQL-5.7改善了面向DML的工作负载
