Question

It seems I’m getting an “impossible WHERE” on a SELECT query. I’ve posted two queries below, which differentiate in the subquery. What these queries do is check to see if a user has saved something once before, before updating a count. I am using SELECT for testing purposes, but the actual query would be using UPDATE:

UPDATE articles SET article_count = article_count+1 
WHERE id = 2343243 AND (
    SELECT COUNT(*) 
    FROM posts as p
    WHERE p.post_id = 2343243 AND p.user_id = 3
) = 1;

The following two queries are what I’m using to test to see if the data is in the table (for testing only):

EXPLAIN 
SELECT a.id 
FROM articles as a 
WHERE a.id = 2343243 AND (
    SELECT COUNT(*) 
    FROM posts as p
    WHERE p.post_id = a.id AND p.user_id = 3
) = 1;

Query 1 returns Impossible WHERE in EXPLAIN.
The select_type of the query #2 is SUBQUERY.

EXPLAIN 
SELECT a.id 
FROM articles as a 
WHERE a.id = 2343243 AND (
    SELECT COUNT(*) 
    FROM posts as p
    WHERE p.post_id = 2343243 AND p.user_id = 3
) = 1;

Query 2 returns Impossible WHERE noticed after reading const tables in EXPLAIN.
The select_type of the Query 2 is DEPENDENT SUBQUERY.

Question: Any ideas on how to make this not an impossible WHERE query? And also, which would be faster?

Answer 1

After reading on Mysql.com about Impossible WHERE, it isn’t really a good idea to work with such a constraint as WHERE 1 = 1 in a query:

Because it is never possible for this condition to be true, the
EXPLAIN statement will show the words Impossible WHERE. Informally, we
at MySQL say that the WHERE has been optimized away.

Mysql.com: http://dev.mysql.com/doc/internals/en/optimizer-eliminating-dead-code.html

I’ve decided to ditch that query for a new query I’ve written that utilizes indexes for both the main query and the subquery which is a faster solution and seemingly less complex:

UPDATE articles 
SET article_count = IF (
    (SELECT count(*) FROM posts WHERE post_id = 2343243 AND user_id = 3) = 1, article_count+1, article_count) 
WHERE id = 2343243;