每次出现页面视图时，wordpress都会在下面发送一个复杂的非索引查询。完全相同的查询被一遍又一遍地发送，似乎是通过一些“缓存”代码传递的。但为什么缓存实际上不阻止反复执行查询？
捕获的查询在每个页面视图上都会重复询问，它是：
# Query_time: 0 Lock_time: 0 Rows_sent: 320 Rows_examined: 1608
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN
(2366,2363,4066,...etc, about 30 entries);
我注意到这是使用日志查询，而不是在mysql中使用索引。
相关的调用堆栈是：
导航菜单中的wp\\u get\\u nav\\u menu项（3）。php（第495行左右）调用get\\u post in post。php（第1461行左右）调用WP Query->Query in Query。php（第2941行左右）调用WP Query->get\\u posts in Query。php（第2767行左右）调用update\\u post\\u缓存在post中。php（大约在第4454行）在post中调用update\\u postmeta\\u缓存。php（第4474行左右）调用meta中的update\\u meta\\u缓存。php（约560）
这使得讨厌的SELECT语句基本上是从wp\\u postmeta获取菜单项的所有信息，这些菜单项的post\\u id在wp\\u term\\u关系中具有term\\u taxonomy\\u id=3。换言之，它将获得一些与菜单栏对应的元数据。
但是，为什么要在每个页面视图上更新缓存并重新查询数据库？我对缓存的工作原理知之甚少（我刚刚开始了解它），这就是我在这里写作的原因。我所能说的是，“cache\\u results”在第1970行附近调用WP Query->get\\u posts时自动打开。这很好，但是为什么每个页面视图上的缓存都会被刷新呢？如果缓存像我通常期望的那样运行，我不明白为什么它会不断地进行这个查询。
如何最好地解决缺少有效缓存的问题？或者这是预期的行为？
（外部参照：http://wordpress.org/support/topic/core-code-caching-issue-w-nav )
