I ran this on Oracle as well and got the same result.

You might as well have written select fid from foo. So the SQL is wrong in that sense and the IN subquery is redundant.

Interesting enough… if this is rewritten as a join

select fid from foo join bar on fid = fid;
it results in a cartesian join which returns all rows in both tables.

Have Fun

Paul

mysql> explain extended select * from foo where fid in (select fid from bar);
+—-+——————–+——-+——-+—————+———+———+——+——+————————–+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+——————–+——-+——-+—————+———+———+——+——+————————–+
| 1 | PRIMARY | foo | index | NULL | PRIMARY | 1 | NULL | 2 | Using where; Using index |
| 2 | DEPENDENT SUBQUERY | bar | ALL | NULL | NULL | NULL | NULL | 2 | Using where |
+—-+——————–+——-+——-+—————+———+———+——+——+————————–+
2 rows in set, 2 warnings (0.00 sec)

mysql> show warnings\G
*************************** 1. row ***************************
Level: Note
Code: 1276
Message: Field or reference ‘test.foo.fid’ of SELECT #2 was resolved in SELECT #1
*************************** 2. row ***************************
Level: Note
Code: 1003
Message: select `test`.`foo`.`fid` AS `fid` from `test`.`foo` where (`test`.`foo`.`fid`,(select 1 AS `Not_used` from `test`.`bar` where ((`test`.`foo`.`fid`) = `test`.`foo`.`fid`)))
2 rows in set (0.00 sec)

mysql>

select fid from foo where fid in (select true);

I just wasn’t sure how the optimizer got to that point — Roland’s comments helped the most for that.

Basically,
select fid from foo where fid in (select fid from bar)
turns into
select fid from foo where fid in (select 1 from bar)
select fid from foo where fid in (select 2 from bar)

(because 1 and 2 are the values of fid).

mysql> select * from foo where fid in (select 90 from bar);
Empty set (0.00 sec)

I’m in agreement with Gary and kimseong

My guess is, the optimizer is evaluating fid as a string, thus returning results:

mysql> select * from foo where ‘fid’ in (select ‘fid’ from bar);
+—–+
| fid |
+—–+
| 1 |
| 2 |
+—–+
2 rows in set (0.00 sec)

You should enter a bug for it I think…

would you still not expect it to work?

“So, should select * from foo where fid in (select fid from bar); work? If so, why is that?”

yes, it should work as the subquery always selects the exact same value for fid as present for the current row in the outer query. So, both occurrences of fid refer to the exact same value and thus, by definition fid in (…fid…) is always true.

Roland.

The short explanation is that
1) fid is resolvable in the outer query - i.o.w it exists already at the topmost level
2) If fid exists at the topmost level, it exists also at the levels beneath that unless masked by a nearer scope
3) the subquery on bar does not define a fid, so fid unambigously points to the fid of the outermost query.
4) the subquery on bar may reference fid from the outermost query.

That says it all.

As a slightly longer explanation, would you have been surprised that this works:

select fid
from foo
where exists (
select null
from bar
where bid = fid
)

Now if you accept this, what about this:

select fid
from foo
where exists (
select fid
from bar
where bid = fid
)

Logically this should not be objectionable - if the WHERE clause can refer to fid, why not the SELECT list?

So if we accept this, then should be able to except that if

select fid
from bar
where bid = fid

executes *within the current context* then surely,

select fid
from bar

must execute too within that same context.

Your last query does not include that context though - fid is not defined when this is used as the outermost query - hence, you get the “unknown column” error.

You say first “certainly a subquery that cannot run” but the whole point is that *because it is a subquery* it can reference items defined elsewhere (in some enclosing scope). So it can run if it is embedded within its particular context. It may of course not be able to run when you strip away the context.