MySQL中UPDATE必须用JOIN结构，如UPDATE t1 JOIN t2 ON t1.id=t2.t1_id SET t1.status=t2.new_status；不支持FROM子句、目标表别名或直接派生表JOIN；跨库兼容应优先使用带WHERE EXISTS的子查询。
MySQL 中用 JOIN 更新的正确写法
MySQL 不支持标准 SQL 的 UPDATE ... FROM 语法，必须用 UPDATE ... JOIN 结构。常见错误是照搬 PostgreSQL 或 SQL Server 写法，导致语法报错。
- 正确形式是：
UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.status = t2.new_status -
JOIN前不能加FROM，也不能把表别名写在UPDATE后（如UPDATE t1 AS a在旧版本会报错） - 若需 WHERE 过滤，放在
SET之后，例如：SET t1.flag = 1 WHERE t2.valid = 1 - 不支持子查询直接出现在
JOIN右侧（如JOIN (SELECT ...) t2），需先建临时表或改用派生表别名
PostgreSQL 和 SQL Server 的标准写法差异
PostgreSQL 支持 UPDATE ... FROM，SQL Server 支持 UPDATE ... FROM 但要求目标表必须有别名；二者看似相似，实际语义和限制不同。
- PostgreSQL：
UPDATE users SET name = u2.name FROM updates u2 WHERE users.id = u2.id——FROM是显式关联，WHERE 必须包含连接条件 - SQL Server：
UPDATE u SET u.email = u2.email FROM users u INNER JOIN updates u2 ON u.id = u2.id—— 目标表u必须带别名，且FROM中的 JOIN 必须明确 - 两者都不允许在
FROM子句中更新同一张表（即不能UPDATE t FROM t JOIN ...），会报错或产生未定义行为
跨数据库可移植的替代方案：用子查询或 CTE
如果项目要兼容 MySQL / PostgreSQL / SQL Server，应避开方言特有的 JOIN 或 FROM 更新语法，改用子查询或 CTE——虽然性能略低，但逻辑清晰、兼容性好。
- 通用子查询写法：
UPDATE users SET status = (SELECT new_status FROM updates WHERE updates.user_id = users.id) WHERE id IN (SELECT user_id FROM updates) - PostgreSQL 和 SQL Server 支持 CTE：
WITH update_data AS (SELECT user_id, new_status FROM updates) UPDATE users SET status = update_data.new_status FROM update_data WHERE users.id = update_data.user_id - MySQL 8.0+ 支持 CTE，但 UPDATE + CTE 仍不被允许，所以 CTE 方案对 MySQL 无效，必须回退到子查询
- 注意子查询返回 NULL 的情况：若
updates中无匹配行，SET会把字段设为NULL，建议加WHERE EXISTS (...)控制范围
容易忽略的事务与锁行为差异
不同数据库在执行 JOIN 更新时获取的锁类型、粒度和持续时间不一样，这直接影响并发表现，不是纯语法问题，但常被忽视。
- MySQL（InnoDB）：会对
JOIN涉及的所有匹配行加行级写锁，包括被更新表和关联表的匹配行 - PostgreSQL：只锁目标表（
users）的更新行，关联表（updates）仅加轻量级共享锁，不影响写入 - SQL Server：默认锁升级策略可能导致整页甚至整表锁，尤其在大结果集时，建议显式加
WITH (ROWLOCK) - 所有数据库中，若 WHERE 条件未命中索引，都可能触发全表扫描+全表锁定，务必检查执行计划
