SQL Server 中必须用 UPDATE ... FROM 而非 SELECT + 手动拼 UPDATE，因其原子执行、避免引号错位与类型转换失败；FROM 是更新语义锚点，需显式 JOIN 并用别名限定字段，否则易导致全量覆盖、笛卡尔积或数据错乱。
SQL Server 中不能用 SELECT ... FROM 直接更新，但可以用 UPDATE ... FROM 语法实现“查完就更”，这是最常用、最安全的关联更新方式。
为什么必须用 UPDATE ... FROM 而不是 SELECT + 手动拼 UPDATE？
因为手动拼 SQL 容易漏条件、引号错位、类型隐式转换失败，且无法原子执行；而 UPDATE ... FROM 是单条语句，事务内自动保证一致性。它本质是把 JOIN 的逻辑复用到更新路径上，不是先查后更——中间不落地、不暴露临时结果。
- 不支持
UPDATE t1 SET ... SELECT ... FROM t2这类写法，会报错Incorrect syntax near the keyword 'SELECT' -
FROM子句在UPDATE中不是可选的：必须显式写出源表别名，并在SET中通过该别名引用字段 - 如果只写
UPDATE t1 SET ...不带FROM，那就只是普通单表更新，没法拉另一张表的数据
UPDATE ... FROM 的标准写法和字段引用规则
核心是：左表（被更新的表）必须出现在 FROM 的 JOIN 链中，且在 SET 中只能通过它的别名赋值；右表（提供数据的表）仅用于读取，不能出现在 SET 左侧。
- 错误写法：
UPDATE people SET city_name = city.name FROM city WHERE people.city_code = city.code—— 缺少 JOIN，WHERE无法跨表关联 - 正确写法：
UPDATE p SET p.city_name = c.name FROM people p INNER JOIN city c ON p.city_code = c.code - 若要只更新有匹配的城市记录，用
INNER JOIN；若想保留没匹配的原值（比如city_code为'008'的行不改），就得加WHERE EXISTS或改用LEFT JOIN+CASE - 更新多个字段时，每个
SET项都必须明确前缀别名，例如：SET p.name = c.name, p.status = 'MAPPED'
容易踩的坑：NULL、重复匹配、无 WHERE 的全量覆盖
这三类问题在线上最常导致数据错乱，且难以回滚。
-
INNER JOIN会导致没匹配上的行被跳过，但如果你本意是“没匹配就清空city_name”，那得额外写UPDATE ... SET city_name = NULL WHERE NOT EXISTS (...) - 如果
city.code不唯一（比如有两条code = '001'），INNER JOIN会产生笛卡尔积，一条people行可能被更新多次，最终值取决于最后匹配到的city.name—— 结果不可预测 - 漏写
WHERE或ON条件时，UPDATE会静默影响所有行。建议操作前先用等价SELECT验证：SELECT p.*, c.name FROM people p INNER JOIN city c ON p.city_code = c.code - 对大表执行前，务必确认是否已建好
JOIN字段索引（如people.city_code和city.code），否则可能锁表几十秒甚至超时
替代方案：MERGE 适合更复杂的场景
当你要同时处理“匹配则更新、不匹配则插入/删除”时，MERGE 比嵌套多个 UPDATE/INSERT 更简洁。但它语法更重，且在某些版本中对并行执行支持较弱。
- 简单更新没必要上
MERGE，UPDATE ... FROM足够清晰高效 -
MERGE的WHEN MATCHED THEN UPDATE部分，字段赋值规则和UPDATE ... FROM一致，仍需用别名限定 - 注意
MERGE在高并发下可能触发死锁，尤其当ON条件涉及非唯一索引时
真正关键的是：别把 FROM 当成辅助子句，它是整个更新语义的锚点。一旦 JOIN 逻辑写歪，结果就不是“部分更新”，而是“全部失控”。上线前务必在测试库跑 SELECT 对照，再加 TOP (10) 试更新。
