SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2=5; 

Therefore, it is safe to convert the query to an inner join: 

SELECT * FROM t1, t2 WHERE t2.column2=5 AND t1.column1=t2.column1; 

In MySQL 8.0.14 and later, trivial WHERE  conditions arising from constant literal expressions are removed during preparation, rather than at a later stage in optimization, by which time joins have already been simplified. Earlier removal of trivial conditions allows the optimizer to convert outer joins to inner joins; this can result in improved plans for queries with outer joins containing trivial conditions in the WHERE  clause, such as this one: 

SELECT * FROM t1 LEFT JOIN t2 ON condition_1  WHERE condition_2  OR 0 = 1 

The optimizer now sees during preparation that 0 = 1 is always false, making OR 0 = 1  redundant, and removes it, leaving this: 

SELECT * FROM t1 LEFT JOIN t2 ON condition_1  where condition_2 

Now the optimizer can rewrite the query as an inner join, like this: 

SELECT * FROM t1 JOIN t2 WHERE condition_1  AND condition_2 

Now the optimizer can use table t2  before table t1  if doing so would result in a better query plan. To provide a hint about the table join order, use optimizer hints; see Section 8.9.3, “Optimizer Hints” . Alternatively, use STRAIGHT_JOIN ; see Section 13.2.10, “SELECT Statement” . However, STRAIGHT_JOIN  may prevent indexes from being used because it disables semijoin transformations; see Section 8.2.2.1, “Optimizing IN and EXISTS Subquery Predicates with Semijoin Transformations” . 

## 8.2.1.10 Outer Join Simplification 

Table expressions in the FROM  clause of a query are simplified in many cases. 

At the parser stage, queries with right outer join operations are converted to equivalent queries containing only left join operations. In the general case, the conversion is performed such that this right join: 

(T1, ...) RIGHT JOIN (T2, ...) ON P(T1, ..., T2, ...) 

Becomes this equivalent left join: 

(T2, ...) LEFT JOIN (T1, ...) ON P(T1, ..., T2, ...) 

All inner join expressions of the form T1 INNER JOIN T2 ON P(T1,T2)  are replaced by the list T1,T2 , P(T1,T2)  being joined as a conjunct to the WHERE  condition (or to the join condition of the embedding join, if there is any). 

When the optimizer evaluates plans for outer join operations, it takes into consideration only plans where, for each such operation, the outer tables are accessed before the inner tables. The optimizer choices are limited because only such plans enable outer joins to be executed using the nested-loop algorithm. 

Consider a query of this form, where R(T2)  greatly narrows the number of matching rows from table T2 : 

SELECT * T1 LEFT JOIN T2 ON P1(T1,T2) WHERE P(T1,T2) AND R(T2) 

If the query is executed as written, the optimizer has no choice but to access the less-restricted table T1 before the more-restricted table T2 , which may produce a very inefficient execution plan. 

Instead, MySQL converts the query to a query with no outer join operation if the WHERE  condition is null- rejected. (That is, it converts the outer join to an inner join.) A condition is said to be null-rejected for an 

