Oracle 5.0 Reference Manual page 702

ref: func
rows: 2
Extra: Using index
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Note
Code: 1003
Message: select (`test`.`t1`.`outer_expr`,
(((`test`.`t1`.`outer_expr`) in t2 on
maybe_null_key checking NULL))) AS `outer_expr IN (SELECT
maybe_null_key FROM t2)` from `test`.`t1`
The additional
OR ... IS NULL
some optimizations within the subquery become inapplicable), but generally this is tolerable.
The situation is much worse when
as "unknown value,"
NULL
• NULL, if the
SELECT
• FALSE, if the
SELECT
For proper evaluation, it is necessary to be able to check whether the
at all, so
outer_expr = inner_expr
because many real world subqueries become very slow unless the equality can be pushed down.
Essentially, there must be different ways to execute the subquery depending on the value of
outer_expr. In MySQL 5.0 before 5.0.36, the optimizer chose speed over distinguishing a
result, so for some queries, you might get a
FALSE
As of MySQL 5.0.36, the optimizer chooses SQL compliance over speed, so it accounts for the
possibility that
outer_expr
If is NULL, to evaluate the following expression, it is necessary to run the
outer_expr
determine whether it produces any rows:
NULL IN (SELECT inner_expr
It is necessary to run the original
mentioned earlier.
On the other hand, when
outer_expr IN (SELECT
be converted to this expression that uses a pushed-down condition:
EXISTS (SELECT 1 FROM ... WHERE
Without this conversion, subqueries will be slow. To solve the dilemma of whether to push down or not
push down conditions into the subquery, the conditions are wrapped in "trigger" functions. Thus, an
expression of the following form:
outer_expr IN (SELECT
is converted into:
EXISTS (SELECT 1 FROM ... WHERE
More generally, if the subquery comparison is based on several pairs of outer and inner expressions,
the conversion takes this comparison:
(oe_1, ..., oe_N) IN (SELECT ie_1, ...,
Optimizing
SELECT
condition makes query execution slightly more complicated (and
outer_expr
NULL IN (SELECT inner_expr ...)
produces any rows
produces no rows
cannot be pushed down into the subquery. This is a problem,
might be NULL.
FROM ... WHERE subquery_where)
here, without any pushed-down equalities of the kind
SELECT
is not NULL, it is absolutely essential that this comparison:
outer_expr
inner_expr FROM ... WHERE subquery_where)
subquery_where
inner_expr FROM ... WHERE subquery_where)
subquery_where
AND trigcond(outer_expr=inner_expr))
ie_N
682
Statements
can be NULL. According to the SQL interpretation of
should evaluate to:
SELECT
result rather than NULL.
FALSE
AND outer_expr=inner_expr)
FROM ... WHERE subquery_where)
has produced any rows
from
NULL
to
SELECT