optimizer_search_depth 过高导致优化器穷举搜索连接顺序，使 explain 和查询均变慢；mysql 默认值 62 在表数≥8时引发搜索空间爆炸，cpu 耗费在计划生成而非执行。
多表 JOIN 查询变慢，特别是 EXPLAIN 本身就要几秒，大概率是 optimizer_search_depth 拖垮了优化器——不是 SQL 写得差，是 MySQL 在“想太多”。
为什么 optimizer_search_depth 会拖慢多表 JOIN
MySQL 默认把 optimizer_search_depth 设为 62（5.5+ 版本），意思是：对 N 个表的 JOIN，优化器会尝试近乎穷举所有可能的连接顺序和访问路径。当表数 ≥ 8，搜索空间爆炸式增长，CPU 花在“找计划”上远超“执行计划”。你看到的现象通常是：
-
EXPLAIN执行时间 ≈ 实际查询时间（说明卡在优化阶段） - 实际数据量小（
- 执行计划本身合理（
type是ref或range，key也选对了），但生成太慢
这不是 bug，是设计取舍：默认追求“理论上最优”，代价是高开销。对 ORM 自动生成的 10+ 表 JOIN（比如 Laravel/Eloquent 的 eager load 过度关联），这参数就是性能杀手。
设成 0 真的靠谱吗？什么时候该用
optimizer_search_depth=0 不是“关优化器”，而是启用自动剪枝策略：内部按 min(表数量, 7) 动态设深度。实测中，20 表 JOIN 从 5 秒降到 50ms，且执行计划质量未下降——因为真实业务中，超过 7 张表的 JOIN 很少真需要全局最优，贪心选前几个关键表顺序就足够好。
- ✅ 适合场景：ORM 生成的宽 JOIN、报表类多维关联、临时分析脚本
- ⚠️ 谨慎场景：核心交易链路中对延迟极度敏感且 JOIN 表数稳定 ≤ 4 的查询（此时默认深度影响小，没必要动）
- ❌ 不适合：依赖固定执行计划做性能压测或审计的环境（设 0 后计划可能随表数微调而变）
注意：SET optimizer_search_depth=0 是会话级，不影响其他连接；若要全局生效，需写入 my.cnf 的 [mysqld] 段并重启。
比调参更关键的三件事
单靠改 optimizer_search_depth 只能治标。真正压住多级 JOIN 性能的，是下面这些动作：
- 用
EXPLAIN FORMAT=JSON看query_block层级的table顺序和access_type，确认是否真因 JOIN 顺序错乱导致回表/全扫——而不是索引缺失 - 检查
optimizer_switch中use_index_extensions=on和condition_fanout_filter=on是否开启（MySQL 5.7+ 默认开），它们直接影响多表条件下推效果 - 对高频 JOIN 的中间结果，考虑物化为临时表（
CREATE TEMPORARY TABLE ... SELECT），把“动态优化”转为“静态路径”，尤其适合子查询嵌套深、过滤强的场景
最后提醒一句：optimizer_search_depth 的坑不在值大，而在你根本没意识到它正在后台疯狂枚举——下次遇到 JOIN 慢，先 EXPLAIN 一下自己，看那几秒到底花在哪。
