mysql中update...join需确保连接字段有索引、小表作驱动表、加where限定范围；postgresql用update...from需防笛卡尔积和连接不唯一；sql server慎用merge，优先选update...from；跨库更新须本地化处理。

UPDATE ... JOIN 在 MySQL 中怎么写才不锁表卡死

MySQL 不支持标准 SQL 的 UPDATE ... FROM，必须用 UPDATE ... JOIN 语法，但直接套用容易触发全表扫描或锁住整张大表。关键在驱动表选择和连接条件是否能走索引。

常见错误现象：UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.status = t2.new_status 执行极慢、SHOW PROCESSLIST 显示 Updating 状态持续数分钟、主从延迟飙升。

• 确保 JOIN 条件字段（如 t2.t1_id）在 t2 上有索引，否则 t2 会全表扫描，拖垮整个更新
• 把小表（或过滤后结果集小的表）放在 JOIN 左侧作为驱动表，MySQL 优化器更可能用它去查大表
• 避免在 SET 子句里调用函数（如 SET t1.updated_at = NOW() 是安全的，但 SET t1.code = UPPER(t2.raw_code) 会阻止部分优化）
• 加 WHERE 限定范围，哪怕只是 WHERE t2.batch_id = 123，也能让优化器避开全表匹配

PostgreSQL 怎么用 FROM 实现类似 JOIN 更新

PostgreSQL 支持标准的 UPDATE ... FROM，语义清晰且通常比 MySQL 的 JOIN 更易控制执行计划，但依然要防“隐式笛卡尔积”。

使用场景：需要根据另一张维度表批量修正事实表字段，比如用 product_dim 更新 sales_fact 中的 category_name。

• 写法必须带别名：UPDATE sales_fact s SET category_name = d.category FROM product_dim d WHERE s.product_id = d.id
• 如果 product_dim 里一个 id 对应多条记录，PostgreSQL 会报错 more than one row returned by a subquery used as an expression —— 这说明连接不唯一，得加 AND d.is_current = true 或用 LIMIT 1（不推荐）收口
• EXPLAIN ANALYZE 必看：确认 Hash Join 的 inner 表是小表，且 Filter 出现在最外层，不是在 Hash 构建之后再筛
• 大表更新前先 VACUUM ANALYZE product_dim，避免统计信息过期导致选错执行计划

SQL Server 的 MERGE 能不能替代 UPDATE JOIN？

能，但慎用。SQL Server 的 MERGE 语法表面简洁，实际在并发更新、触发器、约束检查等方面行为复杂，线上大表批量更新反而更容易出问题。

性能影响：当源表（USING 后的表）无合适索引时，MERGE 可能触发多次扫描；而等价的 UPDATE ... FROM 更容易被优化器识别为单次嵌套循环。

• 除非明确需要“存在则更新、不存在则插入”的 upsert 逻辑，否则别为了省几行代码用 MERGE
• 必须给 ON 条件字段建索引，且建议加上 WITH (INDEX(idx_name)) 提示强制走索引，防止优化器误选低效路径
• 遇到 The target table 't1' of the DML statement cannot have any enabled triggers 错误，不是因为没权限，而是你用了 MERGE 却没关掉目标表上的触发器
• 用 OUTPUT 子句捕获变更行时，注意日志体积暴增——每行变更都会记一条 LOG 记录，大批次下可能填满事务日志

跨库或跨实例更新字段时为什么不能直接 JOIN

绝大多数数据库（MySQL、PostgreSQL、SQL Server）都不允许在单条 UPDATE 语句中跨物理实例 JOIN，报错类似 ERROR 1105 (HY000): Unknown error 或直接拒绝解析。这不是语法限制，而是架构层面隔离了查询计划生成与数据传输边界。

可操作路径只有两条：拉数据到本地，或推逻辑到远端。

• 用 mysqldump --where="batch_id=456" 或 pg_dump -t t2 --inserts 导出关联数据，再 LOAD DATA INFILE 或 COPY 到目标库临时表，最后本地 UPDATE ... JOIN temp_t2
• 在远端库建存储过程，传入 ID 列表（注意长度限制），由它完成更新；或者用 dblink（PostgreSQL）或 OPENQUERY（SQL Server）做远程查询，但仅限读取，不能直接用于 UPDATE 的 FROM 子句
• 不要尝试用应用层循环单条更新——10 万行就是 10 万次 round-trip，网络开销和事务膨胀远超批量处理收益

真正卡住批量更新效率的，往往不是语法本身，而是索引缺失、统计信息陈旧、或误信“一次全量更新最省事”的直觉。每次写完 JOIN 更新语句，先 EXPLAIN 或 EXPLAIN FORMAT=JSON 看执行计划，比调优参数管用十倍。