exists 比 in 更适合增量更新，因其短路特性可跳过大量无关扫描，而 in 需生成完整临时结果集；mysql update 不允许直接引用目标表，须用派生表绕过；子查询无匹配时字段被置为 null，应使用 coalesce 显式回退；注意时间戳精度与时区对齐以避免漏更或重复更。
子查询 WHERE EXISTS 为什么比 IN 更适合增量更新
因为 EXISTS 在找到第一条匹配记录后就短路退出，而 IN 会先执行完整子查询并生成临时结果集，对大表尤其低效。当目标表已有百万级数据、增量源只含几十条变更时，EXISTS 能跳过大量无关扫描。
典型场景：每天同步订单状态变更，只更新 order_id 出现在当日日志表中的那几条。
- 用
WHERE EXISTS (SELECT 1 FROM log_table l WHERE l.order_id = o.order_id AND l.update_time > 'yesterday')—— 索引可用，执行快 - 避免
WHERE order_id IN (SELECT order_id FROM log_table WHERE update_time > 'yesterday')—— 若子查询无索引或返回 NULL，可能全表扫描或意外跳过更新 - 注意：MySQL 5.7+ 对
IN子查询有半连接优化，但前提是你没在子查询里写GROUP BY或HAVING，否则优化器大概率退化回老式嵌套循环
UPDATE + 子查询时别踩“不能直接引用目标表”的坑
MySQL 报错 You can't specify target table 't' for update in FROM clause 是经典陷阱——你不能在 UPDATE t SET x=... WHERE id IN (SELECT id FROM t WHERE ...) 这种写法里直接查同一个表。
- 绕过方式：把子查询包一层派生表，例如
(SELECT id FROM (SELECT id FROM t WHERE condition) AS tmp) - PostgreSQL 和 SQL Server 没这限制，但 MySQL 8.0 仍保留该行为（哪怕加了
WITH也不行，必须用派生表） - 如果子查询涉及多表关联，派生表外层记得给字段起明确别名，否则容易因列名歧义导致更新错行
用子查询做 UPDATE 的值来源时，NULL 值怎么处理
当子查询没匹配到任何行，更新的字段会被设为 NULL，而不是保持原值——这是很多人没意识到的静默行为。
- 安全写法：用
COALESCE((SELECT new_status FROM status_log s WHERE s.order_id = o.order_id ORDER BY ts DESC LIMIT 1), o.status)显式 fallback - 别依赖
LEFT JOIN替代子查询来避 NULL：JOIN 后若没匹配，对应字段也是 NULL，逻辑上没区别，只是写法不同 - 如果业务要求“只更新有新值的行”，就在
WHERE条件里加EXISTS判断，而不是靠子查询返回 NULL 再用IS NOT NULL过滤——后者会让优化器无法下推条件，性能差
对比逻辑要小心时间戳精度和时区
增量更新常依赖 last_modified 字段判断变化，但子查询里如果忽略精度或时区，会导致漏更或重复更。
- PostgreSQL 的
TIMESTAMP WITHOUT TIME ZONE和TIMESTAMP WITH TIME ZONE在子查询中参与比较时，隐式转换可能让索引失效 - MySQL 的
DATETIME默认不带时区，但如果应用写入时用了CONVERT_TZ(NOW(), '+00:00', '+08:00')，而子查询里直接用'2024-06-01'字符串比较，就可能因时区偏移错失数据 - 建议统一用 UTC 存储 + 显式时区转换函数（如
AT TIME ZONE 'UTC'），并在子查询的WHERE条件里对齐精度，比如用updated_at >= '2024-06-01 00:00:00.000000'而不是>= '2024-06-01'
