sql server中update from必须为目标表显式指定别名，set子句列需以该别名限定；多对一join会导致不可预测覆盖，须提前验证或用cte+row_number()去重；禁用逗号连接，坚持显式join并确保join字段有索引。
UPDATE FROM 必须给目标表起别名，否则报错 Msg 107
SQL Server 不允许写 UPDATE table1 SET col = table2.col FROM table1 INNER JOIN table2 ON ... 这种省略别名的语法。它会直接报错：Msg 107, Level 16, State 1: The column prefix 'table1' does not match with a table name or alias name used in the query.
根本原因是：SET 子句中所有列必须明确归属到一个**带别名的目标表**，而这个别名必须在 FROM 子句中首次出现时就定义好。
- 正确写法是
UPDATE t SET t.col = s.col FROM table1 t INNER JOIN table2 s ON t.id = s.id -
t是目标表table1的唯一合法别名，s只是源表别名，不能出现在 SET 左侧 - 即使目标表只出现一次，也**不能省略别名**；哪怕写成
UPDATE t SET t.col = s.col FROM table1 t INNER JOIN table2 s ON t.id = s.id也不行——t必须显式声明
一对多 JOIN 会导致静默覆盖，必须提前验证或聚合
当你执行 UPDATE t SET t.status = s.new_status FROM orders t INNER JOIN order_updates s ON t.order_id = s.order_id，如果 order_updates 中某个 order_id 出现 3 次，那这行 orders 就会被更新 3 次，最终值取决于 SQL Server 内部执行顺序——不可预测、不可重现。
这不是 bug，是设计行为。你得自己控制源头是否“一对一”：
- 先查：运行
SELECT order_id, COUNT(*) FROM order_updates GROUP BY order_id HAVING COUNT(*) > 1，确认有没有重复键 - 有重复？必须聚合或筛选：用 CTE +
ROW_NUMBER()取最新一条，例如WITH src AS (SELECT order_id, new_status, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) rn FROM order_updates) UPDATE t SET t.status = s.new_status FROM orders t INNER JOIN src s ON t.order_id = s.order_id AND s.rn = 1 - 别在 ON 条件里塞
ISNULL(s.order_id, t.order_id)这类表达式——索引失效，性能断崖式下跌
不要用旧式逗号连接，WHERE 里混 JOIN 条件难维护又易出错
像 UPDATE t1 SET t1.name = t2.name FROM table1 t1, table2 t2 WHERE t1.id = t2.id 这种写法虽然能跑通，但隐患极大：
- 缺少显式连接类型（INNER/LEFT），语义模糊；一旦漏写 WHERE 条件，就是笛卡尔积 + 全表更新
- 无法使用 LEFT JOIN 实现“只更新有匹配的行，其余保持原值”，因为逗号语法不支持外连接
- 执行计划更难优化，SQL Server 很可能放弃哈希匹配，退化为嵌套循环
- 多人协作时极易被误改——比如把
t1.id = t2.id错写成t1.id = t1.id，结果全表被设成同一值
坚持用显式 INNER JOIN 或 LEFT JOIN，条件只写在 ON 子句里，逻辑清晰、可读性强、执行稳定。
UPDATE FROM 性能远优于子查询，但前提是索引到位
对百万级订单表补城市字段，用子查询 UPDATE o SET city = (SELECT city FROM customers c WHERE c.id = o.cid) 跑了 47 分钟；换成 UPDATE o SET o.city = c.city FROM orders o INNER JOIN customers c ON o.cid = c.id 只要 83 秒。
差距来自执行计划本质不同：
- 子查询：对
orders每一行，都独立查一次customers表 → N 次索引查找（或全表扫描） - UPDATE FROM：SQL Server 构建
customers的哈希表，再批量匹配 → 1 次构建 + N 次哈希计算 - 但前提是
c.id上有索引；如果没索引，哈希表构建阶段就会卡住，甚至触发内存溢出 - 验证方式：执行前加
SET STATISTICS IO ON，看逻辑读是否随数据量线性增长；若暴涨，优先检查 JOIN 字段索引
真正容易被忽略的是：UPDATE FROM 不会自动帮你建索引，也不会告诉你缺什么索引——它只会默默变慢，直到你发现报表跑不动了才回头查执行计划。
