meta_query w WP_Query: złączenia, indeksy i koszty zapytań

Filtr obejmujący trzy pola własne może utworzyć trzy złączenia z wp_postmeta. Złączenie łączy wiersze tabel, a alias nadaje osobną nazwę danemu użyciu tabeli. Liczba złączeń zależy od warunków i sposobu łączenia warunków, nie tylko od liczby pól.

Metadane przechowują dodatkowe informacje o wpisie, zwykle jako nazwę pola i wartość. WP_Query buduje zapytania o wpisy WordPressa, a SQL jest językiem zapytań bazy danych. Indeks to dodatkowa struktura wyszukiwania ułatwiająca znalezienie pasujących wierszy. Pamięć podręczna zachowuje wcześniejsze wyniki do ponownego użycia.

Istotny jest koszt rzeczywistego zapytania. Rozkład danych, indeksy, wielkość wyniku, sortowanie i trafienia w pamięć podręczną wpływają na obciążenie. Duża tabela metadanych uzasadnia pomiar, ale nie dowodzi powolności każdego filtra.

Co WP_Query tworzy z tablicy

Trzy porównania równości dla różnych kluczy połączone przez AND zwykle wymagają trzech aliasów metadanych. Zgodne klauzule w tej samej grupie mogą współdzielić alias: te same trzy porównania połączone przez OR wymagają jednego złączenia w sprawdzonym rdzeniu WordPressa 7.1.3. Zmienia to jednak znaczenie z „wszystkie warunki” na „co najmniej jeden warunek”. Zamiana AND na OR nie jest poprawną optymalizacją. Poniższy SQL przedstawia uproszczony przypadek AND z czytelnymi aliasami.

SELECT wp_posts.ID FROM wp_posts
  INNER JOIN wp_postmeta pm1 ON wp_posts.ID = pm1.post_id
  INNER JOIN wp_postmeta pm2 ON wp_posts.ID = pm2.post_id
  INNER JOIN wp_postmeta pm3 ON wp_posts.ID = pm3.post_id
WHERE post_type = 'post' AND post_status = 'publish'
  AND ( pm1.meta_key = '_region' AND pm1.meta_value = 'polnoc' )
  AND ( pm2.meta_key = '_poziom' AND pm2.meta_value = 'b' )
  AND ( pm3.meta_key = '_aktywny' AND pm3.meta_value = '1' )
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC

Przykład zawiera trzy złączenia i cztery odwołania do tabel, licząc wp_posts. Grupowanie po identyfikatorze wpisu zapobiega powielaniu ID przy wielu pasujących wierszach metadanych. Ani tekst SQL, ani liczba klauzul nie dowodzą odczytania 500 000 wierszy w celu zwrócenia 40 wyników. Takie twierdzenie wymaga odtwarzalnych danych i planu wykonania.

Standardowe indeksy i możliwe rozszerzenia

Klucz główny jednoznacznie identyfikuje wiersz tabeli. Indeks prefiksowy przechowuje tylko początek tekstu. Optymalizator bazy wybiera sposób wyszukiwania i kolejność złączeń, a plan wykonania opisuje ten wybór.

Standardowy schemat WordPressa ma klucz główny na meta_id, indeks na post_id i indeks prefiksowy na meta_key ze standardową granicą 191 znaków. Rdzeń nie tworzy indeksu na meta_value. LONGTEXT dopuszcza indeksy prefiksowe. Dodatkowy indeks może pomóc wybranym zapytaniom, lecz wymaga oceny rozkładu wartości, długości kluczy, kosztu zapisu i wersji bazy.

Optymalizator może rozpocząć od wpisów albo od klucza metadanych ograniczającego wynik do niewielu wierszy. Dostęp przez post_id to możliwy plan, a nie niezmienna kolejność. Znaczenie mają liczba pasujących wierszy na odwołanie i część pozostająca po zastosowaniu warunku. Nie istnieje uniwersalne minimum 30 wierszy metadanych na wpis.

Operatory i możliwe koszty

Using filesort oznacza dodatkowe sortowanie zamiast wykorzystania kolejności indeksu. Mimo nazwy sortowanie może pozostać w pamięci. Użycie dysku zależy od wielkości wyniku, ustawień i implementacji bazy. Using temporary oznacza użycie tabeli tymczasowej podczas przetwarzania. Same etykiety nie dowodzą przekroczenia czasu ani konieczności przebudowy.

LEFT JOIN zachowuje wpis w wyniku pośrednim nawet bez pasującego wiersza metadanych. IS NULL wybiera następnie wpisy bez takiego dopasowania. Brak klucza można sprawdzić przez LEFT JOIN i IS NULL. Indeks może przyspieszyć wyszukanie pasującego wiersza, a po trafieniu wykluczającym kandydata optymalizator może zakończyć dalsze szukanie. Twierdzenie, że indeks nie pomaga wykazać braku, jest zatem błędne. Nadal znaczenie mają operator WordPressa i wygenerowany SQL.

Metadane, taksonomia czy własna tabela

Taksonomie pasują do wspólnych klasyfikacji, takich jak regiony lub grupy produktów. Standardowa tabela powiązań ma złożony klucz główny na (object_id, term_taxonomy_id), dodatkowy indeks na term_taxonomy_id oraz kolumnę term_order. Zapytanie taksonomiczne również może wymagać wielu złączeń lub podzapytań. Sama nazwa tabeli nie gwarantuje przyspieszenia.

Metadane pozostają rozsądnym wyborem dla wielu niewielkich lub rzadko używanych filtrów. Często przeszukiwane zakresy liczb i sortowane wartości mogą zyskać na osobnej tabeli z odpowiednimi typami kolumn i indeksami. Decyzję powinny określać model danych i pomiar. Późniejszy odczyt metadanych może korzystać z pamięci podręcznej lub zapytania zbiorczego; jeden odczyt SQL na pole nie jest uniwersalnym modelem kosztu.

Pomiar zamiast zgadywania

Po zwykłym wywołaniu WP_Query właściwość $query->request zawiera wygenerowany SQL; zapytanie może już wtedy być wykonane. Filtr posts_request działa przed wysłaniem głównego zapytania o wpisy. Zwykłe EXPLAIN pełnego SELECT przedstawia szacowany plan, nie zmierzony czas. Polecenia analizy z wykonaniem, zależne od bazy, naprawdę uruchamiają zapytanie i należą do odpowiedniej kopii testowej.

EXPLAIN: plan szacowany
key       wybrany indeks
rows      szacowana liczba sprawdzanych wierszy
filtered  szacowany procent pozostałych wierszy (MySQL)
Extra     dodatkowe operacje

rows jest oszacowaniem, a MySQL filtered szacuje procent pozostający po warunku. Znaczenie mają kolejność złączeń i pozostałe wyniki pośrednie. Iloczyn wszystkich wartości rows ani stały dodatek za złączenie nie dowodzą rzeczywistej liczby odczytanych wierszy. Rzetelne porównanie zapisuje wersję bazy, schemat, indeksy, reprezentatywne dane, parametry oraz czasy bez dostępnych wcześniejszych wyników (zimna pamięć podręczna) i z wynikami gotowymi do ponownego użycia (rozgrzana pamięć podręczna).