SQL Server的UPDATE FROM语法在2005及之后版本行为一致，所谓“不一致”实为兼容性级别、隐式类型转换或查询优化器变化所致；需重点检查数据库compatibility_level、列类型匹配度及JOIN键唯一性。
SQL Server 的 UPDATE FROM 语法本身在 2005 及之后所有主流版本（2008、2012、2014、2016、2017、2019、2022）中行为一致——不是版本差异导致问题，而是你遇到的“不一致”大概率来自兼容性级别、隐式类型转换规则或查询优化器路径变化。
兼容性级别影响列绑定和错误提示
即使 SQL Server 实例是 2022，如果数据库的 compatibility_level 设为 110（对应 SQL Server 2012），某些旧版解析逻辑仍会生效。典型表现：
- 在低兼容性级别下，
UPDATE t SET col = s.val FROM tbl t, src s WHERE t.id = s.id这种逗号连接可能被允许（不报错），但在 140+ 级别下更倾向要求显式JOIN -
Msg 8154（对象名重复暴露）在高兼容性级别下触发更严格，尤其当FROM中用了 CTE 或派生表却未加别名时 -
SET子句里省略目标表前缀（如写SET status = t2.new_status而非t1.status = t2.new_status）在低级别下可能侥幸通过，高级别直接报错
隐式转换与 NULL 处理逻辑随版本微调
SQL Server 2016 SP2 起对字符串截断和数值溢出的默认行为变得更严格；2019+ 引入了 ANSI_WARNINGS OFF 下的兼容性修复。这直接影响 UPDATE FROM 中字段赋值结果：
- 若
t2.new_status是VARCHAR(10)，而t1.status是VARCHAR(5)，旧版本可能静默截断，新版本在ARITHABORT ON下抛Msg 8152 - 当
JOIN结果为空（无匹配行），SET表达式求值为NULL：2017+ 对NOT NULL列赋NULL的拦截更早，可能直接中断语句而非留待事务提交时报错 -
datetimevsdatetime2比较时，2016 起默认按更高精度对齐，可能导致原本能匹配的ON条件失效
查询计划重用与参数嗅探引发执行差异
同一句 UPDATE FROM 在不同版本或同一版本不同统计信息下，可能生成完全不同的执行计划，进而影响更新行为：
- SQL Server 2019 引入的“批模式自适应联接”可能让原本稳定的
Nested Loop变成Hash Join，若t2有重复键，Hash Join的输出顺序不可控，加剧“多行更新同一行”的覆盖风险 - 参数化查询中，首次编译用小数据集生成计划，后续大范围执行时复用该计划，导致内存不足或超时——这种现象在 2016+ 的
Query Store开启后更易被观测到，但根源不在语法本身 -
TOP+ORDER BY在UPDATE FROM中（如UPDATE TOP (1000) ... ORDER BY t2.updated_at DESC）在 2014 及之前不支持，在 2016+ 才正式可用
真正要盯住的不是“哪个版本支持”，而是每次部署前确认三件事：当前库的 compatibility_level、目标列是否 NOT NULL 且类型严格匹配、JOIN 条件在源表中是否天然唯一——这些比版本号更容易出问题。
