![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/verbindungstreppe-de.png\")
Was WP_Query aus dem Feld baut<\/h2>\n
Jede Klausel in Daran ist nichts falsch. Es ist die w\u00f6rtliche \u00dcbersetzung des Gew\u00fcnschten, und die Datenbank beantwortet sie richtig – nachdem sie auf einer mittelgro\u00dfen Seite in der Gr\u00f6\u00dfenordnung einer halben Million Zeilen gelesen hat, um vierzig zur\u00fcckzugeben.<\/p>\n Jede Klausel wird deshalb in zwei Bewegungen beantwortet. Die Verbindung findet die Zeilen zu einem Beitrag \u00fcber Die letzte Zeile macht aus einer langsamen Seite eine Zeit\u00fcberschreitung. Nach einem Metawert zu sortieren, l\u00e4sst sich aus keinem Index bedienen; die Datenbank baut also das gesamte Zwischenergebnis auf und sortiert es – und weil Ein Wert, nach dem gefiltert wird, ist keine Eigenschaft eines Beitrags in dem Sinn, in dem ein Untertitel eine ist. Er ist eine Einordnung, und f\u00fcr Einordnungen hat WordPress bereits eine Struktur mit den richtigen Indizes: Die Regel daraus ist kurz. Was gefiltert oder sortiert wird, geh\u00f6rt in eine Taxonomie – oder, wenn die Werte wirklich zahlenm\u00e4\u00dfig und stetig sind, in eine Spalte einer eigenen Tabelle. Was erst gelesen wird, nachdem der Beitrag gefunden ist, kann in den Metadaten bleiben, wo es genau einen Zugriff \u00fcber Die von WP_Query gebaute Abfrage steht vor der Ausf\u00fchrung bereit: In Drei Zeilen mit meta_query<\/code> bekommt einen eigenen Aliasnamen auf wp_postmeta<\/code> und eine eigene Verbindungsbedingung. Zwei Klauseln, zwei Aliasnamen; f\u00fcnf Klauseln, f\u00fcnf. Die Tabelle wird so oft mit sich selbst verbunden, wie es Bedingungen gibt, und jede dieser Verbindungen tr\u00e4gt das volle Gewicht der Tabelle hinter sich her.<\/p>\nSELECT wp_posts.ID FROM wp_posts\n INNER JOIN wp_postmeta pm1 ON wp_posts.ID = pm1.post_id\n INNER JOIN wp_postmeta pm2 ON wp_posts.ID = pm2.post_id\n INNER JOIN wp_postmeta pm3 ON wp_posts.ID = pm3.post_id\nWHERE post_type = 'post' AND post_status = 'publish'\n AND ( pm1.meta_key = '_region' AND pm1.meta_value = 'nord' )\n AND ( pm2.meta_key = '_stufe' AND pm2.meta_value = 'b' )\n AND ( pm3.meta_key = '_aktiv' AND pm3.meta_value = '1' )\nORDER BY wp_posts.post_date DESC<\/code><\/pre>\nDer Index, den es nicht gibt<\/h2>\n
wp_postmeta<\/code> tr\u00e4gt drei Indizes: den Prim\u00e4rschl\u00fcssel auf meta_id<\/code>, einen auf post_id<\/code> und einen auf die ersten 191 Zeichen von meta_key<\/code>. Auf meta_value<\/code> gibt es keinen, und es kann sinnvoll auch keinen geben: Die Spalte ist LONGTEXT<\/code>, und ein Index auf eine Textspalte unbegrenzter L\u00e4nge ist entweder ein Pr\u00e4fix oder gar nichts.<\/p>\npost_id<\/code> – schnell, indiziert, genau wof\u00fcr ein Index da ist. Danach wird der Wert innerhalb jeder dieser Zeilen verglichen, eine nach der anderen, ohne Hilfe von irgendwoher. Der Aufwand ist der Zahl der Metazeilen je Beitrag proportional, und die liegt auf einer Seite mit Seitenbaukasten und ein paar Erweiterungen selten unter drei\u00dfig.<\/p>\nDie Klauseln, die mehr kosten als die anderen<\/h2>\n
\n\n
\n \nKlausel<\/th>\n Was die Datenbank daf\u00fcr tun muss<\/th>\n<\/tr>\n<\/thead>\n \n 'compare' => '='<\/code><\/td>\nder Grundfall: eine Verbindung, ein Zeichenkettenvergleich je Zeile<\/td>\n<\/tr>\n \n 'compare' => 'LIKE'<\/code><\/td>\ndasselbe mit Mustervergleich; ein f\u00fchrender Platzhalter schlie\u00dft jede Abk\u00fcrzung aus<\/td>\n<\/tr>\n \n 'type' => 'NUMERIC'<\/code><\/td>\nlegt CAST()<\/code> um die Spalte und nimmt damit die letzte Aussicht auf Indexnutzung<\/td>\n<\/tr>\n\n 'compare' => 'NOT EXISTS'<\/code><\/td>\neine LEFT JOIN samt IS-NULL-Pr\u00fcfung – jede nicht passende Zeile muss erst entstehen<\/td>\n<\/tr>\n \n 'relation' => 'OR'<\/code><\/td>\ndie Klauseln engen einander nicht mehr ein; die Zwischenmenge ist die Vereinigung<\/td>\n<\/tr>\n \n 'orderby' => 'meta_value'<\/code><\/td>\neine tempor\u00e4re Tabelle und eine Sortierung \u00fcber eine Textspalte<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n meta_value<\/code> ein LONGTEXT<\/code> ist, geschieht diese Sortierung auf der Platte statt im Arbeitsspeicher, sobald die Menge gro\u00df wird.<\/p>\nNOT EXISTS<\/code> verdient eine eigene Warnung. Es liest sich wie das billige Gegenteil von EXISTS<\/code> und ist das Gegenteil von billig: Abwesenheit nachzuweisen hei\u00dft, jeden Kandidaten zu besuchen – und das ist genau das, was ein Index nicht abk\u00fcrzen kann.<\/p>\nWohin der Filter stattdessen geh\u00f6rt<\/h2>\n
wp_term_relationships<\/code> ist auf beiden Spalten indiziert, ein Begriffsfilter ist also eine Verbindung, die vollst\u00e4ndig aus Indizes beantwortet wird, ganz ohne Textvergleich.<\/p>\npost_id<\/code> kostet und sonst nichts.<\/p>\nMessen statt sch\u00e4tzen<\/h2>\n
$query->request<\/code> liegt das fertige SQL, und durch EXPLAIN<\/code> geschickt beantwortet es die einzigen zwei Fragen, auf die es ankommt. Die Spalte rows<\/code> ist die Sch\u00e4tzung, wie viele Zeilen jeder Schritt lesen wird; die Spalte Extra<\/code> benennt die teuren Formen unverbl\u00fcmt, und Using temporary; Using filesort<\/code> zusammen sind die Unterschrift einer Sortierung, die nicht mitw\u00e4chst.<\/p>\nwp db query \"EXPLAIN SELECT wp_posts.ID FROM wp_posts INNER JOIN ...\"\n\nid select_type table type key rows Extra\n1 SIMPLE wp_posts ref type_st. 4800 Using temporary; Using filesort\n1 SIMPLE pm1 ref post_id 40 Using where\n1 SIMPLE pm2 ref post_id 40 Using where\n1 SIMPLE pm3 ref post_id 40 Using where<\/code><\/pre>\nUsing where<\/code> hinter einem Zugriff \u00fcber post_id<\/code> sind genau das oben beschriebene Bild: Der Index hat die Zeilen gefunden, die Bedingung wurde danach angewandt. Die Zahl in rows<\/code>, \u00fcber die Verbindungen multipliziert, ist die Gr\u00f6\u00dfe, die mit der Seite w\u00e4chst – und es lohnt sich, sie an dem Tag zu kennen, an dem die Abfrage geschrieben wird, statt an dem, an dem die Seite nicht mehr l\u00e4dt.<\/p>\n