Condition Filtering条件过滤
本文主要介绍MySQL查询优化中的条件过滤（Condition Filtering，本文翻译为条件过滤），主要翻译自MySQL 8.0 Reference Manual 8.2.1.12 Condition Filtering。
MySQL在处理连接（关联）查询时，会将前一张表（下文称为前导表）满足条件的行传递到下一张待处理的表做关联查询。一般情况下，优化器会优先处理具有小结果集表，然后用尽量少的结果集去处理后面的表，这样能够减少嵌套查询的循环次数，从而能够避免前后表的关联行数据的快速变大。优化器可以根据查询条件尽可能准确的预估满足条件的行数，从而也能选择更好的查询计划。
没有条件过滤时，前导表返回的行数量是基于优化器选择的访问方法（Access method）使用到的WHERE子句中的条件进行估算的。而条件过滤则在此基础上进一步使用没有用于访问方法的剩余条件进行返回行数的估算，这样能够提高估算的准确性。例如，可以使用基于索引的访问方法从当前表中选择数据返回进行下一张表的连接查询，但是通过WHERE子句中没有使用的其他条件可以对访问方法返回的数据进行进一步的过滤，这样能够提高估算的准确性，避免将不满足条件的数据传递给下一张表进行不必要的处理。
WHERE子句中只有满足如下要求的条件，才能用于进行进一步的过滤：
- 仅仅使用当前表的行。
- 条件表达式中仅参考常量或者来自前面表的数据。
- 没有被选用的访问方法（Access method）使用。
在EXPLAIN输出中，rows表示的是根据选择的访问方法（Access method)返回的行数量，filtered就是条件过滤的结果。filtered是百分数的形式，最大值为100，表示没有进行任何过滤，值越小，则表示过滤的效果越明显。
前导表返回的行数（需要传递到下一张表进行关联处理的行数）就是rows和filtered的乘积，即前导表预估行数被条件过滤进行了进一步的过滤。例如，如果rows为1000并且filtered为20%，条件过滤将预估的1000行减少到1000*20% = 200。
如下的查询语句：
SELECT *
FROM employee
JOIN department
ON employee.dept_no = department.dept_no
WHERE employee.first_name = 'John'
AND employee.hire_date BETWEEN '2018-01-01' AND '2018-06-01';
假设：
-
employee表有1024行。 -
department表有12行。 -
employee和department都在dept_no列见了索引。 -
employee在first_name也有一个索引。 - 满足
employee.first_name='john'条件的有8行数据。 - 满足
employee.hire_date BETWEEN '2018-01-01' AND '2018-06-01'条件的有150行。
*同时满足如下条件的有1行数据。
employee.first_name = 'John'
AND employee.hire_date BETWEEN '2018-01-01' AND '2018-06-01';
没有启用条件过滤时EXPLAIN的输出如下图所示：
对于表employee，采用的使用first_name索引的访问方法选择出8条满足条件的数据行。除此之外没有其他任何过滤（即filtered=100），所以这里选择出的所有8行数据都会传递给下一张表进行处理，来自employee的prefix row数量为rows*filtered=8*100%=8。
启用条件过滤时，优化器会使用没有用于访问方法的其他查询条件对访问方法获取的数据进行进一步的过滤。在上面的例子中，优化器通过条件过滤，基于启发式算法会估算出employee.hire_date的BEWTEEN条件过滤效果为16.31%，此时EXPLAIN的输出如下图所示：
此时，prefix row的数量为rows*filtered=8*16.31%=1.3，更加接近于真实的查询结果。
正常情况下，优化器不会对连接查询的最后一张表进行条件过滤计算，因为最后一张表的查询结果集已经不会传递给其他表了。不过在使用EXPLAIN查看查询计划时，为了提供更多的参考信息，优化器会对所有的表进行条件过滤计算，也包括最后一张表。
可用通过optimizer_switch的condition_fanout_filter标识来启用或关闭条件过滤，默认情况下是启用状态。
如果优化器过度估算了条件过滤的效果，此时启用条件过滤的查询效率可能会比禁用条件过滤的效率要差点。在发生这种情况时，可以采用如下措施：
- 如果该列没有被索引，那么可以在该列上建立索引，这样优化器可以得到关于该列值分布的更多信息，也就可以对该列值进行更好的估算。
- 如果该列没有可用的历史统计信息，可以为该列生成历史统计信息(see Section 8.9.6, “Optimizer Statistics”)。
- 尝试改变连接查询的顺序（比如可以使用
STRAIGHT_JOIN等）。 - 禁用该会话的条件过滤优化
SET optimizer_switch = 'condition_fanout_filter=off';
//或者使用optimizer hint
SELECT /*+ SET_VAR(optimizer_switch = 'condition_fanout_filter=off') */ ...
