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 看执行计划，比调优参数管用十倍。
