优先用 EXISTS，别用 IN 更新状态位——尤其当子查询可能返回 NULL 或数据量大时，IN 会静默失效或性能崩塌；因 IN 对 NULL 敏感，遇 NULL 则整个条件恒为 UNKNOWN，导致 UPDATE 不匹配任何行，且不报错；EXISTS 是半连接，只判断存在性，不受 NULL 影响，需写相关子查询并确保关联字段有索引。
直接说结论：优先用 EXISTS，别用 IN 更新状态位——尤其当子查询可能返回 NULL 或数据量大时，IN 会静默失效或性能崩塌。
为什么 IN 在更新中容易出错
IN 对 NULL 敏感：只要子查询结果里有一个 NULL，整个 IN 条件就恒为 UNKNOWN，导致 UPDATE 不匹配任何行，且不报错、不提示。
- 常见场景：子查询含左连接（
LEFT JOIN）、外键未约束非空、或用了COALESCE但漏判NULL -
IN会隐式去重并生成临时结果集，大数据量下内存占用高、执行计划易走全表扫描 - MySQL 5.7+ 和 PostgreSQL 中，若子查询返回超 1000 行，部分版本会直接报错
Subquery returns more than 1 row（实际是语法误用，但用户常误以为是数据问题）
EXISTS 的写法和关键细节
EXISTS 是半连接（semi-join），只关心“是否存在匹配”，不取值、不排序、不去重，天然规避 NULL 陷阱，且优化器更容易命中索引。
- 必须用相关子查询（correlated subquery）：子查询里要引用主表字段，例如
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'pending') - 子查询中
SELECT后面写什么不重要，SELECT 1、SELECT NULL效果一样；但别写SELECT *，某些数据库会多解析字段 - 确保子查询的关联字段（如
user_id）在被查表上有索引，否则EXISTS也会慢成全表扫描
示例（将待处理订单对应用户的 status_flag 设为 1）：
UPDATE users u
SET status_flag = 1
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id
AND o.status = 'pending'
);
批量更新还要注意这三点
真实业务中，光写对语法还不够，这几处最容易掉坑里：
- 没加
WHERE限制范围：比如忘记加AND u.status_flag = 0，导致已更新过的行反复覆盖，引发幂等性问题 - 事务粒度太大：一次更新百万行？建议加
LIMIT（MySQL）或用WHERE id BETWEEN ? AND ?分批，避免锁表过久 - 误用
JOIN更新：虽然 MySQL 支持UPDATE ... JOIN，但它在 PostgreSQL / SQL Server 中不通用，且语义上不如EXISTS清晰——特别是你要更新 A 表、但判断逻辑依赖 B 表的多个条件时，JOIN容易因重复匹配导致意外多更新
最麻烦的其实是子查询本身嵌套了聚合或窗口函数——这时候 EXISTS 依然能用，但得确认外层能否下推过滤条件；如果不行，就得先物化中间结果到临时表再关联。这点很多人试到报错才意识到。
