{"id":10392,"date":"2026-09-12T07:20:00","date_gmt":"2026-09-12T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10392"},"modified":"2026-09-09T17:07:11","modified_gmt":"2026-09-09T15:07:11","slug":"meta_query-in-wp_query-how-each-clause-becomes-a-join-and-what-it-costs","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/wordpress-plugins-tricks\/meta_query-in-wp_query-how-each-clause-becomes-a-join-and-what-it-costs\/","title":{"rendered":"meta_query in WP_Query: How Each Clause Becomes a Join and What It Costs"},"content":{"rendered":"

A page that filters posts by three custom fields is one array in PHP and four joins in SQL. The array reads like a filter; the SQL reads like a table being visited once for every condition, because that is exactly what it is.<\/p>\n

The interesting part is not that it is slow – most sites never grow large enough to care. It is that the cost is invisible in the code that causes it, and that it grows with two things at once: the number of clauses and the size of a table nobody looks at.<\/p>\n

\n\"A
The same result set, four ways of arriving at it. The bar for the base query is not missing; it is three pixels wide.<\/figcaption><\/figure>\n

What WP_Query Builds Out of the Array<\/h2>\n

Each clause in meta_query<\/code> gets its own alias on wp_postmeta<\/code> and its own join condition. Two clauses, two aliases; five clauses, five. The table is joined to itself as many times as there are conditions, and every one of those joins carries the full weight of the table behind it.<\/p>\n

SELECT 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 = 'north' )\n  AND ( pm2.meta_key = '_level'   AND pm2.meta_value = 'b' )\n  AND ( pm3.meta_key = '_active'  AND pm3.meta_value = '1' )\nORDER BY wp_posts.post_date DESC<\/code><\/pre>\n
Nothing here is wrong. It is the literal translation of what was asked for, and the database will answer it correctly – after reading, on a modest site, something in the order of half a million rows to return forty.<\/p>\n
The Index That Does Not Exist<\/h2>\n
wp_postmeta<\/code> carries three indexes: the primary key on meta_id<\/code>, one on post_id<\/code> and one on the first 191 characters of meta_key<\/code>. There is no index on meta_value<\/code>, and there cannot usefully be one: the column is LONGTEXT<\/code>, and an index on a text column of unbounded length is either a prefix or nothing.<\/p>\n
So every clause is answered in two movements. The join finds the rows for a post by post_id<\/code> – fast, indexed, exactly what an index is for. Then the value is compared inside each of those rows, one at a time, with no help from anything. The work is proportional to how many meta rows a post has, which on a site with a page builder and a few plugins is rarely under thirty.<\/p>\n
The Clauses That Cost More Than the Others<\/h2>\n\n\n\n\n\n\n\n\n\n\n
Clause<\/th>\nWhat the database has to do<\/th>\n<\/tr>\n<\/thead>\n
'compare' => '='<\/code><\/td>\nthe baseline: one join, one string comparison per row<\/td>\n<\/tr>\n
'compare' => 'LIKE'<\/code><\/td>\nthe same, with a pattern match; a leading wildcard rules out every shortcut<\/td>\n<\/tr>\n
'type' => 'NUMERIC'<\/code><\/td>\nwraps the column in CAST()<\/code>, which removes any remaining chance of index use<\/td>\n<\/tr>\n
'compare' => 'NOT EXISTS'<\/code><\/td>\na LEFT JOIN plus an IS NULL test – every non-matching row has to be produced first<\/td>\n<\/tr>\n
'relation' => 'OR'<\/code><\/td>\nthe clauses can no longer narrow each other; the intermediate set is the union<\/td>\n<\/tr>\n
'orderby' => 'meta_value'<\/code><\/td>\na temporary table and a filesort over a text column<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The last row is the one that turns a slow page into a timeout. Sorting by a meta value cannot be done from an index, so the database materialises the whole intermediate result and sorts it – and because meta_value<\/code> is LONGTEXT<\/code>, that sort happens on disk rather than in memory as soon as the set is large.<\/p>\n
NOT EXISTS<\/code> deserves its own warning. It reads as the cheap opposite of EXISTS<\/code> and is the opposite of cheap: proving that something is absent means visiting every candidate, which is the one thing an index cannot shorten.<\/p>\n
Where the Filter Belongs Instead<\/h2>\n
A value that is filtered on is not a property of a post in the way a subtitle is. It is a category, and WordPress already has a structure for categories with the right indexes: wp_term_relationships<\/code> is indexed on both of its columns, so a term filter is one join answered entirely from indexes, with no text comparison anywhere.<\/p>\n
The rule that follows is short. Anything used for filtering or sorting belongs in a taxonomy – or, when the values are truly numeric and continuous, in a column of its own table. Anything only ever read after the post has been found can stay in post meta, where it costs a single lookup by post_id<\/code> and nothing else.<\/p>\n
Measuring Instead of Guessing<\/h2>\n
The query built by WP_Query is available before it runs: $query->request<\/code> holds the finished SQL, and running it through EXPLAIN<\/code> answers the only two questions that matter. The rows<\/code> column is the estimate of how many rows each step will read; the Extra<\/code> column names the expensive shapes outright, and Using temporary; Using filesort<\/code> together are the signature of a sort that will not scale.<\/p>\n
wp 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>\n
Three rows saying Using where<\/code> after a post_id<\/code> lookup is the picture described above: the index found the rows, and the condition was applied afterwards. The number in rows<\/code> multiplied across the joins is the figure that grows with the site, and it is worth knowing on the day the query is written rather than on the day the page stops loading.<\/p>\n
\n
Sources<\/h2>\n