mysql 5.7与8.0的update...join语法兼容但优化行为差异大：8.0更激进下推条件、反向驱动表、严格处理隐式类型转换和字符集不一致，并对子查询物化逻辑更复杂，需通过explain验证执行计划。
MySQL 中的 JOIN 更新语法（即 UPDATE ... JOIN）在 5.7 和 8.0 中语义一致、语法兼容，但执行计划和优化行为差异显著——问题通常不出在语法本身，而在于优化器如何处理关联条件、索引选择、物化逻辑及隐式类型转换。
UPDATE ... JOIN 的基本写法没变，但优化器“敢动”了
你写的这句 SQL 在两个版本都能执行：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'processed' WHERE c.country = 'CN' AND o.created_at <p>但它在 8.0 中可能走完全不同的执行路径：5.7 常按书写顺序驱动 <code>orders</code> 表扫描 + 嵌套循环查 <code>customers</code>；8.0 可能反向驱动，先过滤 <code>customers</code> 再反查 <code>orders</code>，尤其当你在 <code>c.country</code> 上有索引而 <code>o.created_at</code> 没有索引时。</p>
- 8.0 默认启用
condition_fanout_filter=on，会更激进地下推WHERE条件到 JOIN 子句内部，影响实际扫描行数 - 5.7 对
UPDATE ... JOIN的谓词下推支持有限，常导致全表扫描后再过滤 -
EXPLAIN UPDATE在 8.0 才真正可用（5.7 不支持），必须用EXPLAIN SELECT模拟等价查询来预判
隐式类型转换引发的索引失效，在 8.0 更严格
如果 orders.customer_id 是 INT，而 customers.id 是 VARCHAR，5.7 可能静默转成字符串比较并走索引（取决于 collation）；8.0 在多数情况下会拒绝隐式转换或强制全表扫描，报 Using where; Using join buffer。
- 检查
EXPLAIN输出中type是否为ref或eq_ref：若是ALL或index，大概率是类型不匹配或缺失索引 - 8.0 对字符集/排序规则不一致更敏感，
utf8mb4_0900_as_csvsutf8mb4_general_ci混用会导致 JOIN 条件无法使用索引 - 修复方式统一：显式 CAST 或统一字段类型，例如
ON o.customer_id = CAST(c.id AS UNSIGNED)
子查询嵌套在 UPDATE ... JOIN 中的退化风险
如果你写的是带子查询的变体，比如：
UPDATE orders o JOIN (SELECT id FROM customers WHERE country = 'CN') c ON o.customer_id = c.id SET o.status = 'processed';
这个写法在 5.7 总是物化为临时表（DERIVED），性能差但可预测；8.0 默认启用 semijoin=on，本应优化，但一旦子查询含 LIMIT、GROUP BY 或外部引用（DEPENDENT SUBQUERY），就会退回到物化，且不会在 EXPLAIN 中明确提示——只看 select_type 变成 DERIVED 和 Extra 出现 Using temporary。
- 8.0 的
optimizer_switch默认开启materialization=on,semijoin=on，但切换逻辑对用户透明 - 若发现性能突降，先执行
SET optimizer_switch='semijoin=off,materialization=off';临时关闭再测 - 更稳的写法是拆成两步：先
CREATE TEMPORARY TABLE tmp_c AS SELECT id FROM customers WHERE country = 'CN';，再JOIN tmp_c
关键点不在语法是否报错，而在于你依赖的执行路径是否还存在——8.0 的优化器更聪明，也更容易“绕过”你凭经验写的索引设计。上线前务必用真实数据量跑 EXPLAIN FORMAT=TREE（8.0）或 EXPLAIN FORMAT=JSON（5.7），而不是只看 SQL 表面是否合法。
