Redshift中两条相似UPDATE语句一报错一正常的原因分析

嘿，我刚好在把T-SQL脚本迁移到Redshift时踩过一模一样的坑，来跟你拆解下这个问题的前因后果、解决办法，还有你提到的那些疑惑：

问题复盘 #

你遇到的情况很典型：

• 用LEFT JOIN关联临时表的UPDATE语句直接报错：Error: Target table must be part of an equijoin predicate
• 但用INNER JOIN关联普通表的UPDATE却能正常执行
• 最后用子查询重构语句解决了报错，但疑惑之前“更新表不能直接放FROM子句”的结论为啥不适用

为啥会报错？Redshift的UPDATE规则 #

Redshift作为OLAP数据库，对UPDATE语句的JOIN逻辑有严格的限制：

• 当你要更新的目标表出现在FROM子句里时，必须通过等值连接（equijoin）和目标表做明确关联，而且不能用LEFT/RIGHT JOIN这类外连接。
• 外连接的问题在于：它会让目标表的行可能被匹配0次、1次甚至多次，Redshift无法确定到底要更新哪一行（或者是否应该更新），所以直接抛出错误来避免数据不一致。

那为啥INNER JOIN的语句能正常跑？因为INNER JOIN本身就是等值连接，而且Redshift能确认这种连接下的行匹配是明确的（当然你得自己保证连接键不会导致一行匹配多行，否则更新结果会不可控），所以允许这种写法。

解决方案：用子查询重构外连接UPDATE #

针对LEFT JOIN这类外连接的场景，把JOIN逻辑包装成子查询，然后在WHERE子句里用等值条件关联目标表，就能满足Redshift的规则。比如你修复后的语句：

UPDATE billing_temp
SET spotlink = btsl.spotlink
FROM
(
    SELECT bt.dupeid,
           sl.spotlink
    FROM billing_temp AS bt
    LEFT JOIN spot_link AS sl
        ON bt.dupeid = sl.dupeid
) AS btsl
WHERE billing_temp.dupeid = btsl.dupeid;

这里子查询先处理好LEFT JOIN的逻辑，再通过billing_temp.dupeid = btsl.dupeid这个等值条件和目标表绑定，完全符合Redshift的equijoin要求，自然就能正常执行了。

关于“更新表不能直接在FROM子句”的疑惑解答 #

这个结论其实是针对**某些OLTP数据库（比如早期MySQL）**的语法限制，而Redshift作为OLAP数据库，在满足特定条件时是允许目标表出现在FROM子句里的——核心条件就是必须有明确的等值连接，能保证行匹配的唯一性。所以你的第二个语句能正常执行，不是之前的结论错了，而是不同数据库的语法规则本来就不一样~

额外提醒 #

• 哪怕是INNER JOIN的UPDATE，也要确保连接键能唯一匹配目标表的行，否则一行被多次更新的话，Redshift不保证更新顺序，最终结果会不可控。
• 所有外连接的UPDATE场景，建议都用子查询+WHERE等值关联的方式重构，避免触发报错。

内容的提问来源于stack exchange，提问作者Mr. Spock