私は10upからいくつかのベストプラクティスを読んでいて、WP_Queryでこれら2つのフラグをfalseに設定することについて言及しています（クエリの内容に応じて）：

• 'update_post_meta_cache' => false：ポストメタが使用されない場合に便利です。
• 'update_post_term_cache' => false：分類用語が使用されない場合に役立ちます。

私はそれのようなものを利用していると仮定していますがupdate_post_caches()、それが何を意味するのか100％も確信していません。誰かがこれらの2つのフラグがa WP_Queryで意味し、それらがどれほど有用であるかを説明できますか？WordPressがどのように物事をキャッシュするかについて多くを知らないので、情報が多ければ多いほど良いのですが、これら2つのフラグに関するよく考えられた答えも受け入れられます。

どこでもオブジェクトキャッシュ

WordPressは、データベースクエリの数をできる限り削減しようとします。

たとえば、メタフィールドまたは分類フィールドを取得するたびに、データベースを照会する前に、WordPressはそれが既に照会されキャッシュに保存されているかどうかを確認し、データベースを照会する代わりにそこから返します。

「キャッシュジョブ」は、WP_Object_Cacheクラスとwp_cache_*関数（そのクラスメソッドのラッパー）を介して実行されます。

キャッシュが存在する場所

デフォルトでは、「キャッシュ」はPHPグローバル変数にすぎません。これはメモリ内にあることを意味しますが、リクエストごとに消えることも意味します。

ただし、ドロップイン（advanced-cache.phpおよび/またはobject-cache.php）を介して、このキャッシュを処理するカスタムの方法を設定することができます。

通常、このドロップインは、単一の要求を「生き残る」ための何らかのキャッシュメカニズムをセットアップするために使用されます。

このため、WPの人々の間では、これらは「永続キャッシュ」プラグインとして知られています（バブルの外では「キャッシュ」と「永続」という言葉はあまり意味をなさない場合でも）。

最近の人気のある選択肢は、MemcachedまたはRedisです。

「永続キャッシュ」プラグインを使用すると、キャッシュがリクエストごとに更新されないため、データベースクエリの数を大幅に減らすことができます。

いくつかの例

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

上記の2行のコードは、最大で1つのデータベースクエリをトリガーします。

実際、カスタムフィールドをクエリすると、その投稿のすべてのフィールドがデータベースから取得され、オブジェクトキャッシュを介してキャッシュされ、その後のリクエストはdbではなくキャッシュからデータをプルします。

同じことがタクソノミー用語についても発生します。WordPressはタクソノミーのすべての用語を一度プルし、それらをキャッシュから返します。

オブジェクトキャッシュはWordPressで非常に広く使用されています。投稿、メタ値、分類だけでなく、ユーザー、コメント、テーマデータも...

何がWP_Queryこのすべてに関係していますか？

WP_Queryデフォルトで、いくつかの投稿をクエリすると、WordPressはデータベース（またはキャッシュされている場合はキャッシュ）からそれらを取得するだけでなく、取得した投稿に関連するすべてのカスタムフィールドとすべての分類のキャッシュも更新します。

したがって、たとえば、を介して、get_the_terms()またはget_post_meta()を介して取得された投稿をループしているときにWP_Query、データベースクエリをトリガーするのではなく、キャッシュから情報を取得します。

いいね、そうじゃない？

ええ、はい、しかし費用がかかります。

メタおよびタクソノミーWP_Queryで投稿をプルするときにWordPressが行うキャッシュ更新「マジック」。update_meta_cacheupdate_object_term_cache

これらの関数のソースコードを見ると、WordPressが各関数でdbクエリを1つ実行するだけでなく、多くの処理を実行していることがわかります。例えば、でupdate_object_term_cacheある7を入れ子になったforeach ...あなたは分類法がたくさんあるし、ページあたりの投稿数が多い場合、これは非常にパフォーマンスではありません。

WP_Query最後に、これらの引数について

何'update_post_meta_cache'と'update_post_term_cache'に設定したときにやっていることはfalse、それぞれ、カスタムフィールドと分類法の更新キャッシュにワードプレスを防ぐためです。

その場合、カスタムフィールドまたは分類法が初めて照会されると、データベースクエリがトリガーされ、データがキャッシュされます。

手間をかける価値はありますか？

いつものように、答えは依存します。これらの値をに設定するほとんどのfalse場合は、不要な処理やデータベースクエリが不要になり、カスタムフィールド/分類条件が初めて必要になったときにキャッシュが更新されるため、適切な選択です。

ただし、get_post_meta()ループ中に一度でも呼び出して、get_the_terms()投稿でサポートされるすべての（またはほとんどの）分類法を呼び出す場合、キャッシュの更新はとにかくトリガーされ、実際の利点はない可能性がありますこれらのクエリ引数をに設定しますfalse。

ここでの主な関心はupdate_post_caches関数です。WP_QueryがDBからすべての投稿を取得した後に呼び出されます。通常、投稿を最初に表示する理由は、それらを表示することです。これは通常、メタデータに基づいて用語や何かを表示することを意味します。キャッシュに保存します*。この情報はWP_Queryから返されたデータでは明示的に利用できませんが、特定の投稿の用語とメタ情報を取得するために関連するAPIを呼び出す場合、既にメモリで利用可能であり、新しいを送信する必要はありませんDBへのクエリ。

これにより、ワードプレスは、各投稿ごとにリクエストを送信するのではなく、すべての投稿の情報を取得するリクエストを1つだけ送信することで、DBへのリクエスト送信に関連するオーバーヘッドを削減できます。

現時点では、キャッシュを更新したくない場合の簡単な例は見つかりませんが、すべての投稿のタイトルのリストが必要な場合は簡単な例です。そのため、用語やメタデータは必要ありません。

*キャッシュ-ここで最も重要なのは、WPがオブジェクトキャッシングプラグインをアクティブにしなくてもDBから取得したすべてをalmotに保存するメモリベースのキャッシュです。明らかにオブジェクトのキャッシュがある場合、情報もそこに保存されます。