mysql执行一条sql可能有多种方案，查询优化器功能就是帮助mysql选择出代价最小的一个方案。

上面方案对于navicat客户端用户是行不通的，如下图所示，可能会很懵逼：

如上图，明明开启了查询优化器并且执行了select可是TRACE里什么也没有，这是因为navicat会帮我们在每一次查询操作后都自动执行一个PROFILING QUERY, 这个我也不是很清楚了，意思就是我们的select语句的trace信息被navicat覆盖掉了。想了两个办法来解决这个问题
办法一

办法二

show variables like ‘%optimizer_trace%’; 查看一下优化器的配置信息

我想既然我关不掉profiling，我把optimizer_trace_limit 调成2总行了吧，如下

调参后的截图如下

还是没有我想要的信息，看来2还是不够，经过我测试，调成4即可

截图如下

终于可以追踪到TRACE信息了，还有一种办法是直接用cmd操作，不用调参，上面这些东西我不知道测了多少次，网上找遍了都找不到，刚开始navicat看不到TRACE信息直接蒙蔽了，还是请教了一个前辈他告诉我navicat的profiling操作，然后自己慢慢摸索的。

先看看takeout_goods表
shop_id和name分别是两个b+树索引
sql语句：select * from takeout_goods where shop_id = ‘7691005’ and name like ‘鱼%’;

我们结合上面的查询分析一下查询优化器TRACE 里面的信息
这里推荐一个网站可以伸缩查看json：json

可以看到TRACE里面有三个阶段：
join_preparation : 准备阶段
join_optmization : 优化阶段
join_execution : 执行阶段

下面我们分别看这三个阶段

join_preparation

select#:N
select#:N代表第几个查询，这个例子我是单select查询，三阶段都是select#:1,如果有union连接多select查询，
会有select#:2

expanded_query:
格式化sql，补充隐藏的表名，列名

join_optmization

这个阶段是我们最需要关注的，这里可以查看到不同方案的代价

condition_processing:
对where条件进行优化处理，不展开json讲了，大致就是三个优化处理，如下
constant_propagation常量传递：a=1 and b>a 优化成a=1 and b>1
equality_propagation等值传递：a=b and b =1 优化成a =1 and b =1
trivial_conditino_removal无用条件移除：a=1 and 1 = 1 优化成 a = 1

substitute_generated_columns:
替换虚拟生成列，这个我不懂，但是不影响我们研究

table_dependencies
处理表的依赖关系，join才用得到，和本例无关，有兴趣的我后面会给一个网址供参考

ref_optimizer_key_uses
该查询使用的索引shop_id

rows_estimation

table: takeout_goods
table_scan:全表扫描

potential_range_indexes:列出表中所有索引，并分析是否可用

忽略几个不关键的直接跳到下面
analyzing_range_alternatives: 这里就是本文的核心了，也是代价最小方案的选择

可以看出来走shop_id索引代价480.71,走name代价861.55

chosen_range_access_summary 这个就是最终选择的方案了

considered_execution_plans
优化器最终选择的执行计划

其他略，更详细的案例请见查询优化器