set session参数对已缓存的预编译语句、分区表、临时表等场景无效，且需配合optimizer_trace定位真实生效情况；关键开关应优先启用materialization、use_index_extensions、condition_fanout_filter。
为什么SET SESSION参数有时不起作用
直接执行SET SESSION optimizer_switch="index_merge=on"后，EXPLAIN没变化，不是语法错，而是优化器在生成执行计划前已固化部分决策逻辑。比如optimizer_search_depth设为0时，优化器跳过连接顺序穷举，但若SQL里有STRAIGHT_JOIN，这个提示会覆盖参数设置；又或者查询涉及分区表、临时表，某些参数根本不生效。
- 只对当前会话后续新查询生效，已缓存的预编译语句（如PreparedStatement）不受影响
-
optimizer_trace必须在查询执行前开启，且仅记录上一条SELECT/UPDATE/DELETE的优化过程 - 部分参数（如
eq_range_index_dive_limit）只在IN列表长度超过阈值时才触发行为变更
哪些optimizer_switch开关最值得动态启用
盲目开一堆开关反而让优化器更难决策。优先关注三个实际影响大的：
-
materialization=on：对IN (SELECT ...)子查询启用物化，避免反复执行——但需配合semijoin=on，否则无效 -
use_index_extensions=on：允许优化器利用索引扩展（如InnoDB主键自动追加到二级索引末尾），对复合索引范围扫描很关键 -
condition_fanout_filter=on：启用条件扇出过滤，在多条件AND查询中更准估算行数，尤其当字段间存在相关性时
禁用要谨慎：index_merge=off可能阻止优化器合并多个单列索引，但若表数据倾斜严重，开启反而导致更差计划。
用optimizer_trace定位参数失效的真实原因
光看EXPLAIN看不出参数是否被采纳。SET optimizer_trace="enabled=on,one_line=off"后执行查询，再查information_schema.OPTIMIZER_TRACE，重点关注"considered_execution_plans"和"best_covering_index_scan"段：
- 若trace里显示
"range_analysis"中"index_dives_for_eq_ranges"为false，说明eq_range_index_dive_limit已触达上限，优化器改用采样估算 - 看到
"analyzing_range_alternatives"但没列出你期望的索引，大概率是该索引因max_seeks_for_key限制被提前排除 - trace末尾
"chosen_plan"里的"cost"值，比EXPLAIN的rows更能反映参数调整是否真降低了估算成本
参数调优必须避开的硬伤场景
有些情况再调参也白搭，得换思路：
- WHERE里对字段用函数，如
WHERE DATE(create_time) = '2026-07-01'——优化器根本不会考虑create_time索引，参数再调也没用，必须重写为范围查询 - 统计信息严重过期，
ANALYZE TABLE没跑过，optimizer_switch所有设置都基于错误基数做成本估算 - 查询含用户自定义函数（UDF）或存储过程调用，优化器无法评估其CPU开销，成本模型失效，参数干预失去意义
真正有效的动态干预，永远建立在准确的统计信息和干净的SQL写法基础上。参数只是微调杠杆，不是万能扳手。
