ERROR 1093是因在UPDATE JOIN中将非目标表字段写在SET左侧，MySQL仅允许更新紧跟UPDATE后的表；正确写法是UPDATE后声明目标表，SET左侧必须为其别名+字段，右侧可引用JOIN表字段。
MySQL中UPDATE JOIN写错目标表位置直接报ERROR 1093
MySQL只允许更新紧跟在UPDATE关键字后面的那张表，其他JOIN表只能当“数据源”，不能被修改。一旦在SET左侧写了非目标表字段，立刻触发ERROR 1093。
- 典型错误：
UPDATE orders o JOIN customers c ON o.cid = c.id SET c.status = 'active'——c是JOIN表，却想改它 - 正确写法：把要更新的表放在
UPDATE后，且SET左侧必须是它的别名+字段，如SET o.status = c.tier - 别名不能省略，哪怕只有一张JOIN表也得写
orders o，否则报ERROR 1066
PostgreSQL/SQL Server漏写WHERE关联条件等于全表覆盖
它们不支持UPDATE ... JOIN，但很多人照搬MySQL写法，在WHERE里只写业务条件（比如status = 'pending'），却忘了绑定两张表的关系，结果所有目标行都被设成同一个值。
- 错误示例：
UPDATE users SET score = logs.points FROM user_logs logs WHERE logs.status = 'done'—— 缺users.id = logs.user_id，数据库随机选一行logs.points赋给全部users.score - PostgreSQL要求
WHERE中必须显式写出两表等值条件，如users.id = logs.user_id - SQL Server允许
FROM users u JOIN logs l ON u.id = l.user_id，但UPDATE后不能加别名，SET里字段仍需前缀
JOIN匹配不到的行默认跳过，不是设NULL
JOIN默认是INNER JOIN，匹配失败的行直接跳过，不会更新——这不是bug，是语义本身。如果你期望“没匹配上的行设为默认值”，就得主动处理。
- 执行
UPDATE orders o JOIN customers c ON o.cid = c.id SET o.level = c.tier后出现Rows matched: 1000 Changed: 720，说明280行因cid在customers里找不到而被跳过 - 想覆盖空匹配，改用
LEFT JOIN，但SET o.level = c.tier会让没匹配的行变成NULL，需加COALESCE(c.tier, o.level)兜底 - 先用
SELECT COUNT(*) FROM orders o LEFT JOIN customers c ON o.cid = c.id WHERE c.id IS NULL确认空匹配比例，再决定是否用LEFT JOIN
没索引、没WHERE或开safe_updates=1时更新可能被拒
JOIN更新本质是先做关联扫描再执行更新，数据量一大就容易慢，还可能引发长事务和行锁等待。更隐蔽的风险是：某些配置会让更新直接失败，连错误提示都不明显。
- 开了
sql_safe_updates=1，而WHERE条件没走索引，MySQL会静默拒绝执行，返回0 rows affected - 别依赖
ROWS AFFECTED == 0判断失败——MySQL/PostgreSQL都静默返回0，ORM框架常当成功处理 - 务必确保
JOIN条件字段（如user_id）和WHERE字段都有索引，否则可能扫全表 - 生产环境务必用事务包裹：
BEGIN; UPDATE ... ; COMMIT;，出错可回滚
实际操作中最容易被忽略的是：**你看到的“执行成功”未必真成功**。0 rows affected可能是没匹配到数据，也可能是safe_updates拦截了，还可能是WHERE条件写错导致过滤失效——得靠SELECT先验证逻辑，再跑UPDATE。
