Optimizing SELECT Statements 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 SELECT * FROM t1 LEFT JOIN t2 ON  condition_1  where  condition_2 SELECT * FROM t1 JOIN t2 WHERE  condition_1  AND  condition_2 The optimizer now sees during preparation that 0 = 1 is always false, making  OR 0 = 1  redundant, and removes it, leaving this: Now the optimizer can rewrite the query as an inner join, like this: 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: Becomes this equivalent left join: (T1, ...) RIGHT JOIN (T2, ...) ON P(T1, ..., T2, ...) (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 1668