{"id":12977,"date":"2026-09-12T07:35:00","date_gmt":"2026-09-12T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12977"},"modified":"2026-10-24T06:23:55","modified_gmt":"2026-10-24T04:23:55","slug":"tutorial-finding-a-slow-meta_query-and-rewriting-it-as-a-taxonomy-filter","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/wordpress-plugins-tricks\/tutorials-en-wordpress-plugins-tricks\/tutorial-finding-a-slow-meta_query-and-rewriting-it-as-a-taxonomy-filter\/","title":{"rendered":"Tutorial: Finding a Slow meta_query and Rewriting It as a Taxonomy Filter"},"content":{"rendered":"

A slow product filter deserves measurement before a data-model change. A meta_query<\/code> can be appropriate; a taxonomy can help categorical filters. Neither the number of joins nor the number of distinct values alone predicts the faster solution. The first requirement is that the rewritten query still selects the same products.<\/p>\n

1. Preserve the complete filter<\/h2>\n

The example searches published products with colour blau<\/code>, material eiche<\/code> and availability 1<\/code>. The original and rewritten query must keep all three conditions, the same ordering and the same pagination. Availability remains a metadata condition here.<\/p>\n

<?php\n$base = [\n    'post_type' => 'produkt',\n    'post_status' => 'publish',\n    'posts_per_page' => 20,\n    'paged' => 1,\n    'orderby' => ['date' => 'DESC', 'ID' => 'DESC'],\n];\n$before = new WP_Query($base + [\n    'meta_query' => [\n        'relation' => 'AND',\n        ['key' => 'farbe', 'value' => 'blau'],\n        ['key' => 'material', 'value' => 'eiche'],\n        ['key' => 'verfuegbar', 'value' => '1'],\n    ],\n]);\n$after = new WP_Query($base + [\n    'tax_query' => [\n        'relation' => 'AND',\n        ['taxonomy' => 'farbe', 'field' => 'slug',\n         'terms' => ['blau'], 'include_children' => false],\n        ['taxonomy' => 'material', 'field' => 'slug',\n         'terms' => ['eiche'], 'include_children' => false],\n    ],\n    'meta_query' => [\n        ['key' => 'verfuegbar', 'value' => '1'],\n    ],\n]);\n\/\/ SQL: $before->request and $after->request\n<\/code><\/pre>\n
This code assumes the custom post type produkt<\/code> and both taxonomies already exist and contain the correct assignments. It is not a WooCommerce query. It executes two queries for comparison; the application would use the chosen version. Equality must be checked across all relevant pages and filter combinations, not only the first twenty results.<\/p>\n
\"Preserve
Preserve filter conditions and verify the migration<\/figcaption><\/figure>\n
2. Inspect actual SQL and its plan<\/h2>\n
$query->request<\/code> contains the generated SQL. The three positive metadata conditions joined by AND normally require three metadata joins in this example. This is not a universal one-clause\/one-join rule: compatible OR clauses can reuse an alias. Logical table aliases are not physical copies of the database table.<\/p>\n
The standard WordPress schema indexes post_id<\/code> and a prefix of meta_key<\/code>, but not meta_value<\/code>. Existing installations may have extra indexes. The optimizer can start from the posts table or another useful access path; it does not invariably scan every row with a particular key. Duplicate metadata rows can expand intermediate results.<\/p>\n
For a protected development request, SAVEQUERIES<\/code> records SQL, execution time and calling information. It adds memory and processing overhead and can expose sensitive values in logs. A database slow-query log provides a different perspective and does not supply the same PHP call path. Its activation requires appropriate privileges, an explicit logging period and consideration of volume. Changing a global session-default setting does not update every existing connection.<\/p>\n
EXPLAIN<\/code> describes an estimated plan. rows<\/code> and filtered<\/code> must be read together with join order, access type and selected indexes. A large estimate alone does not prove that a filter is ineffective. Using filesort<\/code> means an additional sorting operation, not necessarily a disk sort. Using temporary<\/code> is not by itself proof of a bad query. MySQL\u2019s EXPLAIN ANALYZE<\/code> actually executes the statement; MariaDB syntax and behavior must be checked separately.<\/p>\n
meta_value_num<\/code> is numeric ordering, implemented by WordPress as a numeric expression, not a text comparison. Expressions and large intermediate results can increase work, but the earlier claim that sorting normally costs more than all filters had no measured basis.<\/p>\n
3. Register both categorical attributes<\/h2>\n
<?php\nadd_action('init', function () {\n    foreach (['farbe', 'material'] as $taxonomy) {\n        register_taxonomy($taxonomy, ['produkt'], [\n            'hierarchical' => false,\n            'public' => false,\n            'publicly_queryable' => false,\n            'show_ui' => true,\n            'show_admin_column' => true,\n            'show_in_rest' => false,\n            'query_var' => false,\n            'rewrite' => false,\n        ]);\n    }\n});\n<\/code><\/pre>\n
Both farbe<\/code> and material<\/code> are registered. The example disables public taxonomy queries and rewrite routes, while allowing administration. This is not an authorization boundary. Block-editor access requires an appropriate REST configuration, including show_in_rest<\/code>; REST exposure and permissions need their own decision.<\/p>\n
term_relationships<\/code> contains object ID, term-taxonomy ID and term order. Its composite primary key starts with the object ID, and a separate index starts with the term-taxonomy ID. These access paths can help exact category matching. A composite index is not automatically equally useful from either end. A boolean flag is not inherently unsuitable for a taxonomy, and publication status should not be repurposed merely to encode stock availability.<\/p>\n
4. Plan migration before writing<\/h2>\n
The following plan.php<\/code> is deliberately read-only. It covers two example IDs and explicit value mappings; both lists need adapting to the actual inventory. Target terms must already exist. Unknown, empty, duplicate or structured metadata stops the plan instead of silently losing information. Empty values need an explicit policy: retain an assignment, remove it or flag it for review.<\/p>\n
<?php\n\/\/ Read-only example for reviewed IDs, not a complete migration runner.\n$ids = [101, 102];\n$mapping = [\n    'farbe' => ['blau' => 'blau', 'rot' => 'rot'],\n    'material' => ['eiche' => 'eiche', 'buche' => 'buche'],\n];\n$plan = [];\nforeach ($ids as $id) {\n    if (get_post_type($id) !== 'produkt') {\n        throw new RuntimeException("Unexpected post type: $id");\n    }\n    foreach ($mapping as $taxonomy => $values) {\n        if (!taxonomy_exists($taxonomy)) {\n            throw new RuntimeException("Missing taxonomy: $taxonomy");\n        }\n        $raw = get_post_meta($id, $taxonomy, false);\n        if (count($raw) !== 1 || !is_string($raw[0])\n            || !array_key_exists($raw[0], $values)) {\n            throw new RuntimeException("Unmapped or ambiguous value: $id\/$taxonomy");\n        }\n        $term = get_term_by('slug', $values[$raw[0]], $taxonomy);\n        if (!$term || is_wp_error($term)) {\n            throw new RuntimeException("Missing target term: $id\/$taxonomy");\n        }\n        $old = wp_get_object_terms($id, $taxonomy, ['fields' => 'ids']);\n        if (is_wp_error($old)) {\n            throw new RuntimeException($old->get_error_message());\n        }\n        $plan[] = [\n            'post_id' => $id,\n            'taxonomy' => $taxonomy,\n            'source_value' => $raw[0],\n            'old_term_ids' => array_map('intval', $old),\n            'new_term_ids' => [(int) $term->term_id],\n        ];\n    }\n}\necho wp_json_encode($plan, JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE);\n<\/code><\/pre>\n
Execution with wp eval-file plan.php<\/code> prints the proposed assignments. It performs no term assignment or metadata deletion. A complete migration additionally needs bounded batches, a backup of source values and old assignments, a write freeze or synchronization of every writer, and a checked resume strategy.<\/p>\n
After the plan has been reviewed and the current source values and old assignments have been compared again, the following API fragment applies one row. Integer term IDs prevent confusion with numeric term names. The false argument replaces assignments within this taxonomy, so existing terms may be removed.<\/p>\n
<?php\n\/\/ Fragment for one previously reviewed and revalidated plan row.\n$result = wp_set_object_terms(\n    (int) $row['post_id'],\n    array_map('intval', $row['new_term_ids']),\n    $row['taxonomy'],\n    false\n);\nif (is_wp_error($result)) {\n    throw new RuntimeException($result->get_error_message());\n}\n\/\/ Read back term IDs and compare them with new_term_ids.\n<\/code><\/pre>\n
The fragment is not an atomic migration runner. Each write needs read-back verification and error handling; a later failure does not automatically roll back earlier rows. Re-running an old plan after taxonomy edits can overwrite newer work. Automatic slug normalization can merge distinct source values, which is why the mapping is explicit.<\/p>\n
5. Validate behavior before retiring metadata<\/h2>\n
Comparisons should include result IDs, ordering, counts, missing values, duplicate metadata, drafts and scheduled content in migration scope, and multilingual assignments where relevant. Query latency should be measured with comparable data, indexes, cache conditions and workload. No reproducible measurement supports the earlier graphic\u2019s 480,000-versus-2,100-row claim.<\/p>\n
The old command wp post meta delete --all --keys=farbe --dry-run<\/code> was invalid for this task. The documented command requires an object ID; --all<\/code> means all metadata for that object, and no such dry-run option is documented. Old metadata should remain until writers, comparisons and rollback are resolved. Cleanup needs its own explicit scope and backup.<\/p>\n
\n
Questions and answers<\/h2>\n
When is another data model preferable?<\/h3>\n
Numeric ranges may benefit from typed indexed columns or an existing lookup table. Small or selective metadata queries may already be fast. Neither thousands of terms nor a handful of matching rows establishes a universal threshold. Full-text indexes tokenize text and do not automatically support arbitrary substrings.<\/p>\n
What changes for WooCommerce?<\/h3>\n
Existing product attributes, visibility rules and lookup tables should be inspected first. WooCommerce\u2019s product type and data APIs differ from this invented example. A parallel custom taxonomy must not bypass stock, visibility, translation or extension behavior.<\/p>\n<\/div>\n
Sources<\/h2>\n