mysql优化之Outer Join Simplification

在很多情况下，查询的FROM子句中的表达式被简化了。

在解析阶段，具有右外连接操作的查询将转换为仅包含左连接操作的查询。在一般情况下，转换是这样进行的：、

所有形式为T1 INNER JOIN T2 ON P（T1，T2）的内联接表达式都被替换为T1，T2列表，以及作为WHERE条件的P（T1，T2）。

当优化器评估外连接执行计划时，它只考虑对于每个这样的操作，在内表之前访问外部表的情况。优化器的选择是有限的，因为只有这样的计划才能使用嵌套循环算法执行外部连接。

假设下面这种形式的查询，其中R（T2）极大地缩小表T2中匹配行的数量：

如果查询按照上面的语句执行，则优化器别无选择，只能访问限制较多的表T2之前先访问限制较少的表T1，这可能会造成非常低效的执行计划。

相反，如果WHERE条件为null-rejected(如果因为某个外连接操作而产生的补充为NULL的row，并且使用一个条件去判断这行记录的结果是false或者unknown，则这个条件被称为null-rejected)，则MySQL将查询转换为不含外连接操作的查询，也就是说会把外连接转换成内连接。

一个条件对于查询中的某一个外连接操作可能为null-rejected，但是对另外一个外连接操作不是 null-rejected。在下面这个查询中，WHERE条件对于第二个外连接操作为null-rejected，但对第一个外连接操作不为null-rejected：

例如，在前面的查询中，第二个外部联接是null-rejected，因此可以由内部联接替换：

对于原始查询，优化器仅评估与单个表访问顺序T1，T2，T3兼容的计划。对于重写的查询，它另外考虑访问顺序T3，T1，T2。

一个外部联接操作的转换可能触发另一个的转换。下面是这个查询转换的过程：

有时候，优化器可以成功替换embedded 外联接，但不能转换embedding 外联接。以下查询：

任何尝试在查询中转换embedded 的外连接操作都必须考虑embedded 外连接的连接条件以及WHERE条件。在下面的查询中，对于embedded 外连接，WHERE条件不是null-rejected，但embedded 外连接条件T2.A = T1.A AND T3.C = T1.C是null-rejected：