UPDATE配合EXISTS可精准更新已存在主键/业务键的记录，避免误更新或插入；需确保EXISTS子查询相关联、条件一致且源表有索引，JOIN方式通常更高效安全。
UPDATE时用EXISTS判断重复记录是否已存在
SQL的UPDATE本身不支持“存在则更新，不存在则跳过”的原子语义，但配合EXISTS子查询可以精准控制只更新那些**已有对应主键/业务键的记录**，避免误更新或报错。关键不是“覆盖”，而是“有才改”。
常见错误是把EXISTS写在WHERE里却漏掉关联条件，导致全表扫描或逻辑错乱；或者误以为EXISTS能自动插入——它只返回布尔值，不改变数据。
-
EXISTS子查询必须相关（correlated）：内部需引用外部UPDATE的表别名，比如WHERE EXISTS (SELECT 1 FROM tmp t WHERE t.id = u.id) - 别用
IN替代EXISTS：当子查询可能返回NULL时，IN会整体判为FALSE，而EXISTS不受NULL影响 - MySQL 8.0+、PostgreSQL、SQL Server 都支持，但SQLite不支持在
UPDATE ... FROM中直接用EXISTS，得改用WHERE id IN (SELECT id FROM ...)
MySQL中UPDATE + EXISTS的典型写法（5.7+）
MySQL不支持标准的UPDATE ... FROM语法，所以得把EXISTS放在WHERE里，并确保子查询能走索引。
假设要批量更新用户表users中已存在的ID，数据来自临时表tmp_updates：
UPDATE users u
SET name = (SELECT name FROM tmp_updates t WHERE t.id = u.id),
email = (SELECT email FROM tmp_updates t WHERE t.id = u.id)
WHERE EXISTS (SELECT 1 FROM tmp_updates t WHERE t.id = u.id);
注意两点：
- 每个
SET字段都用独立子查询，MySQL不支持UPDATE ... JOIN时直接引用多列（除非用JOIN语法，见下一条） -
WHERE EXISTS必须和SET中的子查询使用相同关联条件，否则执行计划可能退化 - 确保
tmp_updates.id有索引，否则EXISTS会触发全表扫描
更高效：用JOIN替代EXISTS（MySQL / PostgreSQL）
当更新字段较多或性能敏感时，JOIN比多次EXISTS子查询更直观、通常也更快——因为只查一次源表。
MySQL写法：
UPDATE users u
INNER JOIN tmp_updates t ON u.id = t.id
SET u.name = t.name,
u.email = t.email;
PostgreSQL写法（语法不同）：
UPDATE users u
SET name = t.name,
email = t.email
FROM tmp_updates t
WHERE u.id = t.id;
这种写法隐含了“只更新匹配行”的逻辑，本质就是EXISTS的等价展开，但可读性和执行效率更好。唯一要注意的是：某些老版本MySQL（如5.6）对UPDATE ... JOIN的优化器支持较弱，建议加EXPLAIN确认是否用了索引。
为什么不用INSERT ... ON DUPLICATE KEY UPDATE？
如果你的场景其实是“有就更新、无就插入”，那INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或MERGE（PostgreSQL/SQL Server）才是正解。但题目明确是UPDATE + EXISTS，说明业务约束要求：**绝不新增记录，只修已有数据**。
这时候硬套ON DUPLICATE KEY反而危险——万一唯一键没建全，或临时表里混入新ID，就会意外插入脏数据。而EXISTS或JOIN方式天然过滤掉不存在的ID，安全边界更清晰。
真正容易被忽略的是：子查询里的表别名作用域。比如在SET里写(SELECT name FROM tmp_updates WHERE id = u.id)却没给tmp_updates起别名，在复杂嵌套中容易被外层同名表干扰，导致结果为空或报错。
