在使用Materialization（物化）能提高SQL性能的同时，也有必要留意相关SQL是否存在进一步优化空间的可能性。比如下面描述的场景：

从执行计划可看出，MySQL首先物化了子查询（select_type=DERIVED，或者以format=json格式查看执行计划），然后再通过class_id字段对结果集进行过滤。这个SQL从语义上，也可以写成如下形式，若索引合理执行效率会更高。

从这个例子可以看出子查询物化时的一个潜在问题：当子查询本身比较耗费资源或结果集较大时，往往存在较高的优化空间，特别是在外层条件可作用于子查询的情况下。通过条件下推，在执行过程中尽早减少数据访问量，能显著提高性能。本文重点描述将条件下推到物化子查询的场景。

事实上前面提到的查询在5.7版本可以自动重写。打开优化器选项 derived_merge=on 后，查看重写后的语句如下：

  1. select * from (select class_id, avg(score) from score group by class_id) derived1 where class_id  = 10;

出现这种现象的原因是MySQL优化器目前只能对Mergable的视图或子查询进行重写。理解这一概念可以先从视图的两种算法入手：merge 和 temptable。

一般较为复杂的视图或子查询会使用temptable算法类型，包括：

  1. 含有LIMIT的子查询；
  2. UNION 或UNION ALL子查询；
  3. 输出字段中的子查询；

我们也可以显示的通过创建视图来判断子查询是否使用了merge算法。 比如：

我们创建视图时指定使用merge，但是数据库判定该算法不适合因此使用默认的undefined（实际执行过程中使用temptable算法）。

  1. /**
  3. enum enum_view_algorithm {
  5.   VIEW_ALGORITHM_TEMPTABLE = 1,
  6.   VIEW_ALGORITHM_MERGE     = 2

不是所有数据库引擎都完美实现条件下推下推到子查询的功能。对MySQL中使用聚合查询的视图或者from子查询，建议的条件下推原则是：

查询中只依赖于视图或者from子查询输出字段的where 条件能够安全的下推。

同时需要注意条件下推到视图或derived table子查询后所存放的恰当位置：

  1. 若条件是子查询的group 字段，且该条件上有索引，那么将该条件放在子查询的where字句中，性能会更好（HAVING条件中不含聚合函数时，将该条件下推到where字句中过滤整个group）。

对于其他类型的视图或from子查询，也可以通过语义检查的方式进行人工条件下推。