今天我在mysql-error-log中偶然发现了这些行：
2016-05-30T04:50:45.522853Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 1000ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
2016-05-30T04:50:47.523024Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 0ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
...
......最后一行以约0.5 ms的间隔重复约1000次。
当此消息显示时，mysql用户应该做什么？
在互联网上搜索“1000ms意图循环花费0ms”会产生零结果。谷歌提倡不带引号的搜索，但这会产生完全相反的结果 - 其中“预期的循环” - 无论这可能是什么 - 花费了大量的时间（数千到数万毫秒）。
嗯，确切地说：我正在谈论的数据库有一个innodb格式的单个表，其余的是在myisam中 - 这是有充分理由的（比读写多一千多个读数）。我最想知道的是：为什么黑客会这个服务器抱怨innodb周围的任何东西？因为目前还没有使用innodb格式的唯一表格 - 除了我为自己做的一些罕见的实验。但后者可能不可能成为日志条目的原因，因为我在一个多小时后开始了我的工作日。
所以问题仍然存在：什么可能是因为mysql服务器抱怨一个甚至没用过的innodb数据库？有大量的错误消息？
答案 0 :(得分：3)
我们在各个客户端遇到了同样的问题，发现问题是由于将innodb_lru_scan_depth的值从默认值1024设置为128.尽管降低值会减少处理事务所花费的时间，尤其是写入绑定工作负载我认为将值设置得太低会使缓冲池无法跟上清除某些缓冲区和缓冲池脏页面的速度。
在我们的案例中，我们通过将值从128增加到256来看到了显着的改进，但正确的值取决于硬件和负载类型。诀窍是在增加OLTP性能和让MySQL保持缓冲池清洁之间找到正确的值，而不是让page_cleaner需要做很多工作，如上面的消息所述：
“InnoDB：page_cleaner：1000ms意图循环花了***** ms”
可以动态更改值，而无需重新启动MySQL，例如
SET GLOBAL innodb_lru_scan_depth=256;