UPDATE嵌套子查询易触发笛卡尔积，因未用外层字段关联导致全量匹配；正确写法须在子查询WHERE中引用外层表字段，如t2.ref_id = t1.id，并确保索引有效。
UPDATE语句里嵌套子查询为什么容易触发笛卡尔积
因为UPDATE不支持显式JOIN语法，很多人会把子查询直接塞进SET或WHERE里，结果子查询没和外层表建立关联——数据库就把它当静态集合，对每一行都全量匹配。比如外层1万行 × 子查询500行 = 500万次无意义计算，执行慢、锁表久、还可能写错数据。
子查询必须用WHERE关联外层字段，不能只靠FROM
常见错误是写成UPDATE t1 SET col = (SELECT val FROM t2 WHERE t2.id = ?)，但?没绑定到t1的列；或者更糟：UPDATE t1 SET col = (SELECT val FROM t2)，漏掉WHERE条件，直接返回多行报错或静默取第一行（MySQL非严格模式）。
- 正确写法：子查询的
WHERE里必须引用外层表字段，例如WHERE t2.ref_id = t1.id - 如果子查询需多条件关联，全部写进它的
WHERE，不要指望外层UPDATE ... WHERE来过滤子查询范围 - 避免在子查询里用
ORDER BY + LIMIT 1代替关联逻辑——它不保证稳定性，且无法利用索引加速匹配
LEFT JOIN风格的UPDATE要改用JOIN语法，别硬套子查询
想实现“更新t1，拉取t2中最新一条记录的值”，有人写UPDATE t1 SET x = (SELECT y FROM t2 WHERE t2.t1_id = t1.id ORDER BY ts DESC LIMIT 1)。这看似安全，但MySQL 5.7及更早版本对这种相关子查询优化极差，常退化为对每行t1都全表扫t2。
- 优先改用
UPDATE t1 JOIN (SELECT t1_id, y FROM t2 WHERE ... GROUP BY t1_id) t2 ON t1.id = t2.t1_id SET t1.x = t2.y - 若需最新一条，子查询里先用
ROW_NUMBER() OVER (PARTITION BY t1_id ORDER BY ts DESC)筛出rank=1的行，再JOIN - 确保
t2.t1_id有索引，否则JOIN时无法快速定位，照样扫描全表
UPDATE多表时，每个JOIN后必须带ON，且不能把右表条件挪到外层WHERE
MySQL支持UPDATE t1 JOIN t2 ON ... SET ...语法，但很多人误以为可以省略ON，或把过滤条件放最后的WHERE里。例如UPDATE orders o JOIN order_items i ON o.id = i.order_id WHERE i.status = 'shipped'——这实际等效于INNER JOIN，且所有未发货订单会被跳过；而本意可能是“只更新已发货订单的字段”，但逻辑已失控。
- 每个
JOIN后必须紧跟ON，缺一个就变CROSS JOIN - 右表过滤条件（如
i.status = 'shipped'）必须写进对应ON子句，不是WHERE - 多表UPDATE时，检查执行计划里
type是否为ALL或index，若是，大概率是某个ON没生效或字段类型不一致导致索引失效
复杂点在于：UPDATE里的子查询不像SELECT那样能直观看EXPLAIN；得靠EXPLAIN FORMAT=TREE（MySQL 8.0+）或拆成SELECT验证中间结果行数。最容易被忽略的是字段类型隐式转换——比如t1.id是BIGINT，t2.ref_id是VARCHAR，即使值相同，子查询也无法走索引，只能硬扫。
