After updating to 4.0.0, wp-admin pages became very slow for administrators, and some requests hit our long page timeout. Rolling back to 3.10.0 fixed it. We have 3.3M+ rows in our wp_postmeta table.

CAUSE

includes/multi-authors/wpa-guest-authors-legacy.php, lines 8-37:

function awpa_register_legacy_migration_menu() {
    if (!current_user_can('manage_options')) { return; }
    ...
    $orphaned_meta_count = (int) $wpdb->get_var(
        "SELECT COUNT(*) FROM {$wpdb->postmeta} WHERE meta_value LIKE '%guest-%'"
    );
    if ($guest_count > 0 || $orphaned_meta_count > 0) { add_submenu_page(...); }
}
add_action('admin_menu', 'awpa_register_legacy_migration_menu', 65);

admin_menu fires on every wp-admin page load, so for every user with manage_options this query runs on every admin page.

The result isn’t cached, and it’s only used to decide whether to show the “Migrate Guests” submenu.

In the wp_postmeta table, the meta_value column is an unindexed longtext, and the leading % rules out any index and MySQL scans the whole table. I ran EXPLAIN on the query on our prod site and it did scan all 3367457 rows.

I considered adding an index to solve this but that wouldn’t have helped because of the leading % rules out the index being used.