• LIMIT 

• UNION  or UNION ALL 

•Subqueries in the select list 

•Assignments to user variables 

•Refererences only to literal values (in this case, there is no underlying table) 

If the optimizer chooses the materialization strategy rather than merging for a derived table, it handles the query as follows: 

•The optimizer postpones derived table materialization until its contents are needed during query execution. This improves performance because delaying materialization may result in not having to do it at all. Consider a query that joins the result of a derived table to another table: If the optimizer processes that other table first and finds that it returns no rows, the join need not be carried out further and the optimizer can completely skip materializing the derived table. 

•During query execution, the optimizer may add an index to a derived table to speed up row retrieval from it. 

Consider the following EXPLAIN  statement, for a SELECT  query that contains a derived table: 

EXPLAIN SELECT * FROM (SELECT * FROM t1) AS derived_t1; 

The optimizer avoids materializing the derived table by delaying it until the result is needed during SELECT execution. In this case, the query is not executed (because it occurs in an EXPLAIN  statement), so the result is never needed. 

Even for queries that are executed, delay of derived table materialization may enable the optimizer to avoid materialization entirely. When this happens, query execution is quicker by the time needed to perform materialization. Consider the following query, which joins the result of a derived table to another table: 

SELECT * FROM t1 JOIN (SELECT t2.f1 FROM t2) AS derived_t2 ON t1.f2=derived_t2.f1 WHERE t1.f1 > 0; 

If the optimization processes t1  first and the WHERE  clause produces an empty result, the join must necessarily be empty and the derived table need not be materialized. 

For cases when a derived table requires materialization, the optimizer may add an index to the materialized table to speed up access to it. If such an index enables ref  access to the table, it can greatly reduce amount of data read during query execution. Consider the following query: 

SELECT *  FROM t1 JOIN (SELECT DISTINCT f1 FROM t2) AS derived_t2 ON t1.f1=derived_t2.f1; 

The optimizer constructs an index over column f1  from derived_t2  if doing so would enable use of ref access for the lowest cost execution plan. After adding the index, the optimizer can treat the materialized derived table the same as a regular table with an index, and it benefits similarly from the generated index. The overhead of index creation is negligible compared to the cost of query execution without the index. If ref  access would result in higher cost than some other access method, the optimizer creates no index and loses nothing. 

For optimizer trace output, a merged derived table or view reference is not shown as a node. Only its underlying tables appear in the top query’s plan. 

