{"id":12981,"date":"2026-09-12T18:25:00","date_gmt":"2026-09-12T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12981"},"modified":"2026-09-09T17:26:02","modified_gmt":"2026-09-09T15:26:02","slug":"tutorial-jak-znalezc-wolne-meta_query-i-przepisac-je-na-filtr-taksonomii","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/wordpress-plugins-tricks-pl\/tutorials-pl-wordpress-plugins-tricks-pl\/tutorial-jak-znalezc-wolne-meta_query-i-przepisac-je-na-filtr-taksonomii\/","title":{"rendered":"Tutorial: Jak znale\u017a\u0107 wolne meta_query i przepisa\u0107 je na filtr taksonomii"},"content":{"rendered":"

Filtr napisany jako meta_query<\/code> wygl\u0105da w PHP niewinnie. Trzy warunki, ka\u017cdy jako tablica, a mi\u0119dzy nimi powi\u0105zanie. To, co dociera do MySQL, jest czym\u015b zupe\u0142nie innym: trzy dodatkowe z\u0142\u0105czenia na tabeli zawieraj\u0105cej ka\u017cde pole dodatkowe ka\u017cdego wpisu w instalacji, kt\u00f3rej rozstrzygaj\u0105ca kolumna nie ma \u017cadnego indeksu.<\/p>\n

Poni\u017csza przebudowa ma cztery kroki – odczyta\u0107 SQL, zmierzy\u0107 go, przenie\u015b\u0107 filtr do taksonomii, jednorazowo przenie\u015b\u0107 warto\u015bci. Op\u0142aca si\u0119 dok\u0142adnie dla jednego rodzaju pola, a ostatni rozdzia\u0142 m\u00f3wi, dla kt\u00f3rego.<\/p>\n

\n\"Por\u00f3wnanie
Ten sam filtr, dwa modele danych. Zmienia si\u0119 nie liczba z\u0142\u0105cze\u0144, lecz to, co MySQL potrafi osi\u0105gn\u0105\u0107 przez indeks.<\/figcaption><\/figure>\n

Co WP_Query buduje z tablicy<\/h2>\n

Zapytanie z trzema warunkami na polach dodatkowych pisze si\u0119 kr\u00f3tko, a wykonuje d\u0142ugo.<\/p>\n

$q = new WP_Query( [\n    'post_type'  => 'produkt',\n    'meta_query' => [\n        'relation' => 'AND',\n        [ 'key' => 'farbe',     'value' => 'blau' ],\n        [ 'key' => 'material',  'value' => 'eiche' ],\n        [ 'key' => 'verfuegbar','value' => '1' ],\n    ],\n] );<\/code><\/pre>\n
Ka\u017cda klauzula staje si\u0119 osobnym z\u0142\u0105czeniem z w\u0142asnym aliasem, bo pojedynczy wiersz wp_postmeta<\/code> niesie zawsze tylko jeden klucz. Trzy warunki potrzebuj\u0105 wi\u0119c trzech kopii tabeli.<\/p>\n
SELECT wp_posts.ID FROM wp_posts\n  INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id\n  INNER JOIN wp_postmeta AS mt1 ON wp_posts.ID = mt1.post_id\n  INNER JOIN wp_postmeta AS mt2 ON wp_posts.ID = mt2.post_id\nWHERE wp_posts.post_type = 'produkt'\n  AND ( wp_postmeta.meta_key = 'farbe'      AND wp_postmeta.meta_value = 'blau' )\n  AND ( mt1.meta_key        = 'material'    AND mt1.meta_value        = 'eiche' )\n  AND ( mt2.meta_key        = 'verfuegbar'  AND mt2.meta_value        = '1' )\nGROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC<\/code><\/pre>\n
Rozstrzygaj\u0105ce stoi w ostatniej linii ka\u017cdego warunku. wp_postmeta<\/code> przynosi indeks na post_id<\/code> oraz na meta_key<\/code>, ale \u017cadnego na meta_value<\/code> – kolumna jest typu LONGTEXT<\/code> i nie da si\u0119 jej zaindeksowa\u0107 w ca\u0142o\u015bci. MySQL znajduje wi\u0119c szybko wszystkie wiersze z kluczem farbe<\/code>, a potem musi obejrze\u0107 ka\u017cdy z nich, aby sprawdzi\u0107 warto\u015b\u0107 blau<\/code>.<\/p>\n
Jak drogie to b\u0119dzie, zale\u017cy od liczby, kt\u00f3rej nikt nie obserwuje: ile wierszy dzieli ten sam klucz. Pole obecne przy ka\u017cdym produkcie ma tyle wierszy, ile jest produkt\u00f3w – a trzy takie pola mno\u017c\u0105 si\u0119 w z\u0142\u0105czeniu.<\/p>\n
Znalezienie zapytania zamiast zgadywania<\/h2>\n
Zanim cokolwiek zostanie przebudowane, zapytanie musi le\u017ce\u0107 na stole. Dwie linie w wp-config.php<\/code> ka\u017c\u0105 WordPressowi zapisywa\u0107 ka\u017cd\u0105 wys\u0142an\u0105 instrukcj\u0119.<\/p>\n
define( 'SAVEQUERIES', true );<\/code><\/pre>\n
Potem da si\u0119 wypisa\u0107 najwolniejsze instrukcje jednego wywo\u0142ania strony – wraz ze \u015bcie\u017ck\u0105 wywo\u0142a\u0144, kt\u00f3ra je stworzy\u0142a, a to zwykle ciekawsza po\u0142owa.<\/p>\n
add_action( 'shutdown', function () {\n    global $wpdb;\n    if ( ! defined( 'SAVEQUERIES' ) || ! SAVEQUERIES ) { return; }\n    $langsam = array_filter( $wpdb->queries, fn( $q ) => $q[1] > 0.05 );\n    usort( $langsam, fn( $a, $b ) => $b[1] <=> $a[1] );\n    foreach ( array_slice( $langsam, 0, 5 ) as $q ) {\n        error_log( sprintf( \"%.3f s  %s\\n   %s\", $q[1], $q[2], substr( $q[0], 0, 400 ) ) );\n    }\n} );<\/code><\/pre>\n
Na dzia\u0142aj\u0105cej witrynie t\u0119 sam\u0105 informacj\u0119 daje dziennik wolnych zapyta\u0144, ca\u0142kiem bez ingerencji w kod – i to lepsze \u017ar\u00f3d\u0142o, bo obejmuje tak\u017ce wywo\u0142ania, kt\u00f3rych nikt nie obserwuje.<\/p>\n
SET GLOBAL slow_query_log = 'ON';\nSET GLOBAL long_query_time = 0.2;\nSET GLOBAL log_queries_not_using_indexes = 'ON';<\/code><\/pre>\n
Odczyt wyniku EXPLAIN<\/h2>\n
Gdy instrukcja jest ju\u017c znana, jedno polecenie m\u00f3wi, co MySQL zamierza z ni\u0105 zrobi\u0107.<\/p>\n
EXPLAIN SELECT wp_posts.ID FROM wp_posts\n  INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id\n  ...<\/code><\/pre>\n
Wynik nios\u0105 trzy kolumny. rows<\/code> szacuje, ile wierszy zostaje obejrzanych w ka\u017cdej tabeli, a iloczyn po wszystkich tabelach to z grubsza nak\u0142ad pracy. key<\/code> podaje u\u017cyty indeks – tutaj meta_key<\/code>, nigdy meta_value<\/code>. A w Extra<\/code> stoj\u0105 dwie uwagi warte reakcji: Using temporary<\/code> i Using filesort<\/code>.<\/p>\n
Druga z nich ma w\u0142asn\u0105 przyczyn\u0119. Sortowanie po polu dodatkowym zamienia sortowanie w por\u00f3wnanie tekstu na kolumnie bez indeksu – dlatego dodane 'orderby' => 'meta_value_num'<\/code> kosztuje cz\u0119sto wi\u0119cej ni\u017c wszystkie trzy filtry razem.<\/p>\n\n\n\n\n\n\n\n\n
Obserwacja<\/th>\nZnaczenie<\/th>\n<\/tr>\n<\/thead>\n
key = meta_key<\/td>\nKlucz zostaje znaleziony przez indeks, warto\u015b\u0107 nie<\/td>\n<\/tr>\n
rows w dziesi\u0105tkach tysi\u0119cy<\/td>\nPole wisi przy niemal ka\u017cdym wpisie – filtr niczego nie zaw\u0119\u017ca<\/td>\n<\/tr>\n
Using filesort<\/td>\nSortowanie nast\u0119puje po z\u0142\u0105czeniu, na ca\u0142ym wyniku<\/td>\n<\/tr>\n
Using temporary<\/td>\nGROUP BY wymaga tabeli tymczasowej, zwykle z powodu wielu z\u0142\u0105cze\u0144<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Przeniesienie filtra do taksonomii<\/h2>\n
To, \u017ce taksonomia jest szybsza, nie bierze si\u0119 z jakiej\u015b szczeg\u00f3lnej przemy\u015blno\u015bci WordPressa. Bierze si\u0119 st\u0105d, \u017ce wp_term_relationships<\/code> przechowuje w wierszu dwie liczby ca\u0142kowite i ma klucz g\u0142\u00f3wny w\u0142a\u015bnie po tych dw\u00f3ch kolumnach – z\u0142\u0105czenie biegnie wi\u0119c z obu stron przez indeks.<\/p>\n
add_action( 'init', function () {\n    register_taxonomy( 'farbe', 'produkt', [\n        'hierarchical'      => false,\n        'public'            => false,\n        'show_ui'           => true,\n        'show_admin_column' => true,\n        'query_var'         => false,\n        'rewrite'           => false,\n    ] );\n} );<\/code><\/pre>\n
Dwa ustawienia zas\u0142uguj\u0105 na chwil\u0119 uwagi. public => false<\/code> trzyma strony archiwum i adresy poza witryn\u0105, a w\u0142a\u015bnie tego chce czysta cecha filtruj\u0105ca. A show_admin_column<\/code> nic nie kosztuje i pokazuje warto\u015bci na li\u015bcie wpis\u00f3w – tam nieudane przeniesienie rzuca si\u0119 w oczy najwcze\u015bniej.<\/p>\n
Zapytanie po zmianie opisuje ten sam filtr innym s\u0142ownictwem.<\/p>\n
$q = new WP_Query( [\n    'post_type' => 'produkt',\n    'tax_query' => [\n        'relation' => 'AND',\n        [ 'taxonomy' => 'farbe',    'field' => 'slug', 'terms' => 'blau' ],\n        [ 'taxonomy' => 'material', 'field' => 'slug', 'terms' => 'eiche' ],\n    ],\n] );<\/code><\/pre>\n
S\u0142owo o trzecim warunku pierwotnego zapytania: pole typu tak-nie, jak verfuegbar<\/code>, r\u00f3wnie\u017c nie nale\u017cy do taksonomii. Dwa terminy na dziesi\u0119\u0107 tysi\u0119cy produkt\u00f3w oznaczaj\u0105, \u017ce jeden termin niesie dziewi\u0119\u0107 tysi\u0119cy przypisa\u0144, a indeks na kolumnie o dw\u00f3ch r\u00f3\u017cnych warto\u015bciach jest niemal bezwarto\u015bciowy. Taki znacznik lepiej mie\u015bci si\u0119 w post_status<\/code>, w osobnej taksonomii stan\u00f3w obok innych stan\u00f3w – albo zostaje w postmeta jako jedyna pozosta\u0142a klauzula: jedno z\u0142\u0105czenie nie jest problemem, trzy s\u0105.<\/p>\n
Jednorazowe przeniesienie istniej\u0105cych warto\u015bci<\/h2>\n
Taksonomia istnieje, wpisy nic o niej jeszcze nie wiedz\u0105. Jednorazowy przebieg przez WP-CLI przenosi warto\u015bci i daje si\u0119 wcze\u015bniej sprawdzi\u0107.<\/p>\n
wp eval '\n$ids = get_posts( [ \"post_type\" => \"produkt\", \"posts_per_page\" => -1,\n                    \"fields\" => \"ids\", \"post_status\" => \"any\" ] );\n$n = 0;\nforeach ( $ids as $id ) {\n    $wert = get_post_meta( $id, \"farbe\", true );\n    if ( $wert === \"\" ) { continue; }\n    wp_set_object_terms( $id, sanitize_title( $wert ), \"farbe\", false );\n    $n++;\n}\necho \"$n wpisow\\n\";\n'<\/code><\/pre>\n
O powtarzalno\u015bci tego przebiegu rozstrzygaj\u0105 trzy szczeg\u00f3\u0142y. post_status => any<\/code> obejmuje tak\u017ce szkice i wpisy zaplanowane – w\u0142a\u015bnie te, kt\u00f3rych brak ujawnia si\u0119 p\u00f3\u017aniej. false<\/code> w wp_set_object_terms<\/code> zast\u0119puje przypisanie, zamiast je uzupe\u0142nia\u0107, dzi\u0119ki czemu drugi przebieg daje ten sam stan, a nie rosn\u0105c\u0105 list\u0119. A sanitize_title<\/code> sprawia, \u017ce termin zostaje znaleziony po slugu, wi\u0119c z Blau<\/code> i blau<\/code> powstaje jeden termin, a nie dwa.<\/p>\n
Wiersze postmeta najlepiej zostawi\u0107 jeszcze na jaki\u015b czas. Gdy nowa droga podzia\u0142a kilka tygodni, znikn\u0105 jedn\u0105 instrukcj\u0105 – i dopiero wtedy, bo ten krok nie ma drogi powrotnej.<\/p>\n
wp post meta delete --all --keys=farbe --dry-run<\/code><\/pre>\n
Kiedy taksonomia jest z\u0142\u0105 odpowiedzi\u0105<\/h2>\n
Przebudowa op\u0142aca si\u0119 przy polach o niewielu r\u00f3\u017cnych warto\u015bciach, s\u0142u\u017c\u0105cych jako filtr. Dla trzech innych przypadk\u00f3w jest chwytem b\u0142\u0119dnym, a ka\u017cdy z nich ma w\u0142asn\u0105 lepsz\u0105 odpowied\u017a.<\/p>\n
Najwyra\u017aniejsze s\u0105 zakresy liczbowe. Cena, data, waga – wszystko, o co pyta si\u0119 przez BETWEEN<\/code> albo por\u00f3wnanie, nie ma godnych uwagi termin\u00f3w, a taksonomia z o\u015bmioma tysi\u0105cami termin\u00f3w jest gorsza od zast\u0105pionego postmeta. Takie pole nale\u017cy do w\u0142asnej kolumny, we w\u0142asnej tabeli z indeksem po dok\u0142adnie tej odpytywanej kombinacji.<\/p>\n
Drugim przypadkiem jest wyszukiwanie pe\u0142notekstowe. Terminy trafiaj\u0105 dok\u0142adnie albo wcale; szukanie cz\u0119\u015bci s\u0142owa wymaga indeksu FULLTEXT<\/code> albo osobnego indeksu wyszukiwania, a \u017cadne z nich nie jest taksonomi\u0105.<\/p>\n
Trzecim przypadkiem s\u0105 warto\u015bci wisz\u0105ce tylko przy garstce wpis\u00f3w. Pole przy dwudziestu z czterdziestu tysi\u0119cy produkt\u00f3w jest wystarczaj\u0105co rozr\u00f3\u017cniaj\u0105ce ju\u017c przez sam meta_key<\/code>, a zapytanie dzia\u0142a szybko bez \u017cadnej zmiany. Narz\u0119dziem tej decyzji jest jedno zliczenie, wykonane przed ka\u017cd\u0105 przebudow\u0105.<\/p>\n
SELECT meta_key, COUNT(*) AS zeilen, COUNT(DISTINCT meta_value) AS werte\nFROM wp_postmeta GROUP BY meta_key ORDER BY zeilen DESC LIMIT 20;<\/code><\/pre>\n
Wiele wierszy i ma\u0142o r\u00f3\u017cnych warto\u015bci – to przypadek, dla kt\u00f3rego taksonomia powsta\u0142a. Wiele wierszy i prawie tyle samo r\u00f3\u017cnych warto\u015bci domaga si\u0119 kolumny. Ma\u0142o wierszy oznacza, \u017ce nie musi si\u0119 dzia\u0107 nic.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n