{"id":12979,"date":"2026-09-12T12:45:00","date_gmt":"2026-09-12T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12979"},"modified":"2026-10-24T06:23:55","modified_gmt":"2026-10-24T04:23:55","slug":"tutorial-eine-langsame-meta_query-finden-und-in-einen-taxonomie-filter","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/tutorial-eine-langsame-meta_query-finden-und-in-einen-taxonomie-filter\/","title":{"rendered":"Tutorial: Eine langsame meta_query finden und in einen Taxonomie-Filter umbauen"},"content":{"rendered":"

Ein langsamer Produktfilter sollte vor einem Wechsel des Datenmodells gemessen werden. Eine meta_query<\/code> kann passend sein; eine Taxonomie kann kategoriale Filter unterst\u00fctzen. Weder die Anzahl der Verbindungen noch die Zahl verschiedener Werte allein sagt die schnellere L\u00f6sung voraus. Zuerst muss die neue Abfrage weiterhin dieselben Produkte ausw\u00e4hlen.<\/p>\n

1. Den vollst\u00e4ndigen Filter erhalten<\/h2>\n

Das Beispiel sucht ver\u00f6ffentlichte Produkte mit Farbe blau<\/code>, Material eiche<\/code> und Verf\u00fcgbarkeit 1<\/code>. Vorher und nachher m\u00fcssen alle drei Bedingungen, dieselbe Sortierung und dieselbe Seiteneinteilung gelten. Die Verf\u00fcgbarkeit bleibt hier eine Metadatenbedingung.<\/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
Der Code setzt den eigenen Beitragstyp produkt<\/code> sowie beide Taxonomien mit korrekten Zuordnungen voraus. Eine WooCommerce-Abfrage ist das nicht. Zum Vergleich werden zwei Abfragen ausgef\u00fchrt; die Anwendung w\u00fcrde die gew\u00e4hlte Fassung verwenden. Der Ergebnisabgleich muss alle relevanten Seiten und Filterkombinationen erfassen, nicht nur die ersten zwanzig Treffer.<\/p>\n
\"Filterbedingungen
Filterbedingungen erhalten und Migration pr\u00fcfen<\/figcaption><\/figure>\n
2. Tats\u00e4chliches SQL und Abfrageplan untersuchen<\/h2>\n
$query->request<\/code> enth\u00e4lt das erzeugte SQL. Die drei positiven Metadatenbedingungen mit AND ben\u00f6tigen in diesem Beispiel \u00fcblicherweise drei Metadatenverbindungen. Eine allgemeine Regel \u201eeine Klausel, eine Verbindung\u201c folgt daraus nicht: Passende OR-Klauseln k\u00f6nnen einen Alias gemeinsam verwenden. Logische Tabellenaliase sind keine physischen Kopien der Datenbanktabelle.<\/p>\n
Das WordPress-Standardschema indiziert post_id<\/code> und ein Pr\u00e4fix von meta_key<\/code>, aber nicht meta_value<\/code>. Bestehende Installationen k\u00f6nnen zus\u00e4tzliche Indizes besitzen. Der Optimierer kann bei der Beitragstabelle oder einem anderen geeigneten Zugriffspfad beginnen; s\u00e4mtliche Zeilen eines Schl\u00fcssels werden nicht zwangsl\u00e4ufig durchsucht. Doppelte Metadatenzeilen k\u00f6nnen Zwischenergebnisse vergr\u00f6\u00dfern.<\/p>\n
F\u00fcr einen gesch\u00fctzten Entwicklungsaufruf zeichnet SAVEQUERIES<\/code> SQL, Laufzeit und Aufrufinformationen auf. Das ben\u00f6tigt zus\u00e4tzlichen Speicher und Rechenzeit; Protokolle k\u00f6nnen vertrauliche Werte enthalten. Ein Datenbankprotokoll langsamer Abfragen zeigt eine andere Perspektive und liefert nicht denselben PHP-Aufrufpfad. Die Aktivierung ben\u00f6tigt passende Rechte, einen begrenzten Messzeitraum und eine Absch\u00e4tzung der Protokollmenge. Ein global ge\u00e4nderter Sitzungsvorgabewert aktualisiert nicht jede bestehende Verbindung.<\/p>\n
EXPLAIN<\/code> beschreibt einen gesch\u00e4tzten Plan. rows<\/code> und filtered<\/code> geh\u00f6ren zusammen mit Verbindungsreihenfolge, Zugriffstyp und gew\u00e4hlten Indizes gelesen. Eine gro\u00dfe Sch\u00e4tzung allein beweist keinen wirkungslosen Filter. Using filesort<\/code> bedeutet einen zus\u00e4tzlichen Sortierschritt, nicht zwingend eine Sortierung auf Festplatte. Using temporary<\/code> ist f\u00fcr sich kein Nachweis einer schlechten Abfrage. MySQLs EXPLAIN ANALYZE<\/code> f\u00fchrt die Anweisung tats\u00e4chlich aus; Syntax und Verhalten unter MariaDB sind gesondert zu pr\u00fcfen.<\/p>\n
meta_value_num<\/code> sortiert numerisch. WordPress verwendet daf\u00fcr einen numerischen Ausdruck, keinen Textvergleich. Ausdr\u00fccke und gro\u00dfe Zwischenergebnisse k\u00f6nnen den Aufwand erh\u00f6hen; die fr\u00fchere Behauptung, Sortieren koste normalerweise mehr als alle Filter, war jedoch nicht durch Messungen belegt.<\/p>\n
3. Beide kategorialen Merkmale registrieren<\/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
Registriert werden sowohl farbe<\/code> als auch material<\/code>. Das Beispiel deaktiviert \u00f6ffentliche Taxonomieabfragen und Rewrite-Routen, erlaubt aber die Verwaltung. Eine Zugriffskontrolle entsteht dadurch nicht. F\u00fcr den Blockeditor ist eine passende REST-Konfiguration einschlie\u00dflich show_in_rest<\/code> erforderlich; Ver\u00f6ffentlichung und Berechtigungen der REST-Daten sind gesondert festzulegen.<\/p>\n
term_relationships<\/code> enth\u00e4lt Objekt-ID, Term-Taxonomie-ID und Begriffsreihenfolge. Der zusammengesetzte Prim\u00e4rschl\u00fcssel beginnt mit der Objekt-ID; ein eigener Index beginnt mit der Term-Taxonomie-ID. Diese Zugriffspfade k\u00f6nnen genaue Kategorievergleiche unterst\u00fctzen. Ein zusammengesetzter Index ist nicht automatisch von beiden Enden gleich gut nutzbar. Ein Ja-Nein-Merkmal ist nicht grunds\u00e4tzlich ungeeignet f\u00fcr eine Taxonomie. Der Ver\u00f6ffentlichungsstatus sollte nicht lediglich zur Abbildung von Lagerverf\u00fcgbarkeit umgedeutet werden.<\/p>\n
4. Die Migration vor Schreibzugriffen planen<\/h2>\n
Die folgende plan.php<\/code> liest ausschlie\u00dflich. Enthalten sind zwei Beispiel-IDs und ausdr\u00fcckliche Wertzuordnungen; beide Listen m\u00fcssen zum tats\u00e4chlichen Bestand passen. Die Zielbegriffe m\u00fcssen bereits existieren. Unbekannte, leere, doppelte oder strukturierte Metadaten brechen die Planung ab, statt Informationen still zu verlieren. Leere Werte ben\u00f6tigen eine festgelegte Regel: Zuordnung erhalten, entfernen oder zur Pr\u00fcfung markieren.<\/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
wp eval-file plan.php<\/code> gibt die vorgesehenen Zuordnungen aus. Begriffszuordnungen und Metadaten werden dabei nicht ver\u00e4ndert. Eine vollst\u00e4ndige Migration ben\u00f6tigt zus\u00e4tzlich begrenzte Verarbeitungspakete, eine Sicherung der Quellwerte und bisherigen Zuordnungen, eine Schreibpause oder Synchronisierung s\u00e4mtlicher Schreiber sowie einen gepr\u00fcften Wiederaufnahmepfad.<\/p>\n
Nach Pr\u00fcfung des Plans und erneutem Vergleich aktueller Quellwerte und bisheriger Zuordnungen wendet das folgende API-Fragment eine Zeile an. Ganzzahlige Begriffs-IDs vermeiden Verwechslungen mit numerischen Begriffsnamen. Das Argument false ersetzt Zuordnungen innerhalb dieser Taxonomie; vorhandene Begriffe k\u00f6nnen dadurch entfallen.<\/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
Das Fragment ist kein atomarer Migrationslauf. Jeder Schreibzugriff ben\u00f6tigt R\u00fccklesen und Fehlerbehandlung; ein sp\u00e4terer Fehler setzt fr\u00fchere Zeilen nicht automatisch zur\u00fcck. Ein alter Plan kann nach neueren Taxonomie\u00e4nderungen aktuelle Arbeit \u00fcberschreiben. Automatische Slug-Normalisierung kann unterschiedliche Quellwerte zusammenf\u00fchren, weshalb die Zuordnung ausdr\u00fccklich festgelegt wird.<\/p>\n
5. Verhalten pr\u00fcfen, bevor Metadaten entfallen<\/h2>\n
Zum Vergleich geh\u00f6ren Ergebnis-IDs, Reihenfolge, Trefferzahlen, fehlende Werte, doppelte Metadaten, Entw\u00fcrfe und geplante Inhalte im Migrationsumfang sowie gegebenenfalls mehrsprachige Zuordnungen. Laufzeiten ben\u00f6tigen vergleichbare Daten, Indizes, Cachezust\u00e4nde und Lastbedingungen. F\u00fcr die fr\u00fcheren Grafikwerte von 480.000 gegen\u00fcber 2.100 betrachteten Zeilen liegt keine reproduzierbare Messung vor.<\/p>\n
Der fr\u00fchere Befehl wp post meta delete --all --keys=farbe --dry-run<\/code> war f\u00fcr diese Aufgabe ung\u00fcltig. Der dokumentierte Befehl ben\u00f6tigt eine Objekt-ID; --all<\/code> bezeichnet s\u00e4mtliche Metadaten dieses Objekts, und ein solcher Dry-run-Schalter ist nicht dokumentiert. Alte Metadaten sollten bis zur Kl\u00e4rung von Schreibern, Vergleichen und R\u00fcckweg bestehen bleiben. Die Bereinigung ben\u00f6tigt einen eigenen klaren Umfang und eine Sicherung.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Wann ist ein anderes Datenmodell sinnvoll?<\/h3>\n
Zahlenbereiche k\u00f6nnen von typisierten indizierten Spalten oder einer vorhandenen Nachschlagetabelle profitieren. Kleine oder selektive Metadatenabfragen k\u00f6nnen bereits schnell sein. Weder tausende Begriffe noch wenige passende Zeilen ergeben eine allgemeing\u00fcltige Grenze. Volltextindizes zerlegen Text in Suchbegriffe und unterst\u00fctzen nicht automatisch beliebige Wortteile.<\/p>\n
Was gilt bei WooCommerce?<\/h3>\n
Zuerst sind vorhandene Produkteigenschaften, Sichtbarkeitsregeln und Nachschlagetabellen zu untersuchen. Beitragstyp und Daten-APIs von WooCommerce unterscheiden sich vom erfundenen Beispiel. Eine parallele eigene Taxonomie darf Lagerbestand, Sichtbarkeit, \u00dcbersetzungen oder Erweiterungsverhalten nicht umgehen.<\/p>\n<\/div>\n
Quellen<\/h2>\n