8.8.5. Controlling the Query Optimizer（控制查询优化）

    MySQL提供了优化通过系统变量会影响查询计划进行评估并启用切换优化控制。

8.8.5.1. Controlling Query Plan Evaluation

    相对于计划它计算可使用两个系统变量来控制数优化的行为：

• 该optimizer_prune_level[549]变量告诉优化跳过基于每个表中访问的行数的估计某些计划。我们的经验表明，这种“猜测”很少错过最佳方案，并可显着降低查询编译时间。这就是为什么这个选项（optimizer_prune_level=1），在默认情况下。但是，如果你认为优化错过了一个更好的查询计划，该选项可以被关闭（optimizer_prune_level= 0）与风险查询编译可能需要更长的时间。需要注意的是，即使使用此启发式扫描，优化还是探索计划粗略呈指数数目。
  
  
• 该optimizer_search_depth[550]变量告诉优化程序如何远到每个不完整计划的“未来”看起来，以评估是否应进一步扩大。optimizer_search_depth[550]较小的值可能会导致幅度较小查询编译时间的顺序。例如，用12，13，或多个表的查询可以容易地要求小时甚至几天来编译如果optimizer_search_depth[550]是接近在查询表的数目。

8.8.5.2. Controlling Switchable Optimizations

    该optimizer_switch[550]系统变量使得在优化行为的控制。它的值是一组标志，每个具有的开或关的值，以指示相应的优化器行为是否被启用或禁用。

    要看到当前的一组优化的标志，选择变量值：

mysql> SELECT @@optimizer_switch\G

*************************** 1. row ***************************

@@optimizer_switch: index_merge=on,index_merge_union=on,

index_merge_sort_union=on,

index_merge_intersection=on,

engine_condition_pushdown=on,

index_condition_pushdown=on,

mrr=on,mrr_cost_based=on,

block_nested_loop=on,batched_key_access=off,

materialization=on,semijoin=on,loosescan=on,

firstmatch=on,

subquery_materialization_cost_based=on,

use_index_extensions=on

    要改变optimizer_switch[550]的值，分配一个值由逗号分隔的一个或多个命令列表：

SET [GLOBAL|SESSION] optimizer_switch='command[,command]...';

    变量解释如下：

        
    

  
可以如下设置变量值：

mysql> SET optimizer_switch='index_merge_union=off,index_merge_sort_union=off';

mysql> SELECT @@optimizer_switch\G

********************************************* 1. row *************************** ******************

@@optimizer_switch: index_merge=on,index_merge_union=off,

index_merge_sort_union=off,

index_merge_intersection=on,

engine_condition_pushdown=on,

index_condition_pushdown=on,

mrr=on,mrr_cost_based=on,

block_nested_loop=on,batched_key_access=off,

materialization=on,semijoin=on,loosescan=on,

firstmatch=on,

subquery_materialization_cost_based=on,

use_index_extensions=on