优化器面对多表join时并非不愿找最优解，而是因搜索空间指数爆炸（如4表24种、6表720种顺序）被迫在毫秒内启用启发式剪枝；mysql默认只穷举前72种（optimizer_search_depth=6），postgresql设join_collapse_limit=8，超限后直接放弃全局搜索，仅保留带where条件的表在左端等简化策略，导致实际执行常偏离真实最优路径。
优化器不是“不想找最优解”，而是面对复杂 JOIN 时，根本找不到——它必须在毫秒级内做决定，而搜索空间早已指数爆炸。
为什么4张表JOIN就可能让优化器“放弃思考”
4 张表理论上存在 24 种合法连接顺序（4!），5 张表是 120 种，6 张表飙升到 720 种。MySQL 默认只穷举前 72 种（optimizer_search_depth=6），PostgreSQL 也设了硬限制（join_collapse_limit 默认 8）。一旦超过阈值，优化器直接启用启发式剪枝：跳过明显差的路径，但不再验证是否漏掉真正最优的那个。
- 它优先保留带 WHERE 条件的表在左端，但若条件选择性差（如
status IN ('a','b','c')覆盖 80% 数据），这个“优先”反而误导 - 统计信息过期或直方图粒度粗（如只记录值频次，不记录分布倾斜），会让优化器把“95% 行都满足
type='normal'”的字段当成高选择性字段，错误选它当驱动表 -
EXPLAIN中看到rows预估为 1 或 10，但实际执行扫了 100 万行——这不是 bug，是估算彻底失准
ON子句里写函数，等于主动关掉优化器的索引雷达
只要 ON 中对任意连接字段用了函数，比如 ON UPPER(u.name) = UPPER(o.buyer_name)，优化器立刻放弃使用 u.name 或 o.buyer_name 上的任何索引。它转而尝试哈希连接或块嵌套循环（Using join buffer (Block Nested Loop)），而这两种策略在中间结果集稍大时就会触发磁盘临时表。
- 隐式转换更隐蔽：
ON o.user_id = u.id，但o.user_id是VARCHAR、u.id是BIGINT→ MySQL 内部转成字符串比对 → 索引失效 -
ON a.created_at::DATE = b.date（PostgreSQL）或DATE(a.created_at) = '2024-01-01'（MySQL）→ 同样绕过索引，强制每行计算 - 修复方式不是“加索引”，而是改写：
a.created_at >= '2024-01-01' AND a.created_at
中间结果集膨胀到优化器不敢信自己的眼睛
优化器依赖 cardinality（基数）估算关联后行数，但一对多关系 + NULL + 重复值会让这个数字完全失真。比如 orders 和 order_items 关联，EXPLAIN 显示预估 5000 行，实际生成 30 万行 —— 这时候优化器后续所有决策（是否用临时表、是否排序、是否下推条件）都建立在错误前提上。
- 用
SELECT COUNT(*) FROM orders GROUP BY order_id HAVING COUNT(*) > 1查主键重复，比盲目调优更有效 - LEFT JOIN 后在右表字段加
WHERE（如WHERE u.status = 'active'），逻辑上等价于 INNER JOIN，但优化器仍按外连接计划执行，保留全部左表行再过滤，中间结果白膨胀 - 真正关键的是
EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）——看“Actual Rows”和“Rows Removed by Filter”这两列，它们比rows那列诚实得多
最常被忽略的一点：优化器的“最优”，是基于当前统计信息、内存配置、超时参数下的局部最优，不是业务意义上的最优。你看到的执行计划，已经是它在 10 毫秒内能给出的最好答案——而这个答案，常常离真实瓶颈差了一层数据分布的真相。
