Performance: Implement a dedicated last_changed key for metadata cache groups to isolate query cache invalidation

[spacedmonkey]

The Problem

WordPress query classes (WP_Query, WP_User_Query, etc.) utilize a last_changed value stored within their respective main object cache groups (e.g., posts, users) to salt generated cache keys. This ensures that when an object is modified, any cached queries referencing that object type are invalidated.

Currently, Core hooks all metadata alterations directly into these primary object cache invalidations:

<?php
add_action( 'added_post_meta', 'wp_cache_set_posts_last_changed' );
add_action( 'updated_post_meta', 'wp_cache_set_posts_last_changed' );
add_action( 'deleted_post_meta', 'wp_cache_set_posts_last_changed' );

This architectural coupling causes significant performance degradation. Frequent metadata updates (e.g., updating a post view counter, modifying an editorial lock timestamp, or updating transaction data) force a bump to the global posts last_changed value. As a result, all standard cached queries for that object type are completely invalidated.

A metadata modification should only invalidate a cached query if that query specifically queries against or joins the metadata tables (e.g., via a meta_query). Standard queries that filter exclusively by core columns (like post_type, post_status, or ID arrays) are unaffected by metadata changes, yet their caches are routinely destroyed by them.

The Proposed Solution

Introduce a dedicated last_changed key specifically for the metadata cache group (e.g., post_meta, user_meta, comment_meta, term_meta) to decouple it from the primary object cache invalidation logic.

Trac ticket: https://core.trac.wordpress.org/ticket/65487

## Use of AI Tools