UPDATE不能直接修改计算列，因其值由表达式动态生成且不物理存储；必须更新其依赖的基础列，计算列会在查询时自动重新计算。
UPDATE 不能直接修改计算列
计算列（computed column）是 SQL Server 中由表达式定义、不物理存储的列，比如 FullName AS FirstName + ' ' + LastName。你无法对它执行 UPDATE —— 语句会直接报错 Cannot update a computed column。
真正要改的是它的源列（FirstName、LastName），计算列值会在查询时自动重新计算。所以别想着“更新计算列”，而是检查哪些基础列驱动了它，然后去更新那些列。
- 用
SELECT COLUMN_NAME, IS_COMPUTED FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'YourTable'快速确认哪些列是计算列 - 如果误写了
SET ComputedCol = ...，SQL Server 会立刻拒绝，不会静默忽略 - 试图在
INSERT或UPDATE中显式提供计算列的值，也会触发相同错误
UPDATE 视图时必须满足可更新性条件
不是所有视图都能被 UPDATE。SQL Server 只允许更新“可更新视图”（updatable view），前提是它背后只引用一个基表，且不包含聚合、DISTINCT、GROUP BY、子查询（非相关）、UNION 等破坏行映射的操作。
常见失败场景：
- 视图用了
JOIN多个表 → 报错View or function 'xxx' is not updatable because the modification affects multiple base tables - 视图含
AVG()或COUNT(*)→ 直接拒绝，不提示具体原因，只报语法错误类提示 - 视图定义中用了
TOP或OFFSET-FETCH→ 不可更新，即使逻辑上只涉及单表
如果你确实需要通过视图写入，优先考虑用 INSTEAD OF UPDATE 触发器接管逻辑，而不是硬改视图定义。
带 JOIN 的 UPDATE 写法（SQL Server 特有语法）
SQL Server 允许在 UPDATE 语句里用 FROM 子句做多表关联更新，这是绕过视图限制的常用实操手段。但它不是标准 SQL，其他数据库（如 PostgreSQL、MySQL）不支持这种写法。
典型结构：
UPDATE t1 SET t1.Status = 'Processed' FROM Orders t1 INNER JOIN Customers t2 ON t1.CustomerID = t2.ID WHERE t2.Country = 'China';
注意点：
-
UPDATE后面只能跟目标表的别名（如t1），不能写全名或 schema 前缀 -
FROM中的表可以是视图，但最终被更新的仍必须是基表中可更新的那一张 - 如果
JOIN导致一行匹配多行（例如一对多），SQL Server 会更新多次，结果取决于执行计划顺序——这容易引发数据逻辑错误，务必加WHERE或用EXISTS控制范围
计算列依赖的函数或 UDF 改变后需手动刷新统计
如果计算列依赖用户自定义函数（UDF），而你后来修改了该函数逻辑，已存在的计算列值**不会自动重算**——它只在下次读取时按新逻辑计算。但如果你开了持久化（PERSISTED），那旧值就真错了，且不会主动同步。
此时必须强制刷新：要么重建计算列（ALTER TABLE ... DROP COLUMN; ADD COLUMN ... PERSISTED），要么对整表运行 UPDATE 触发重算（比如 UPDATE YourTable SET ID = ID，前提是 ID 是主键且无副作用）。
更隐蔽的风险是统计信息未更新：UPDATE STATISTICS 不会自动覆盖计算列的统计，尤其当它被索引化后。建议在变更 UDF 后，手动执行 UPDATE STATISTICS YourTable 并检查 DBCC SHOW_STATISTICS 输出中的直方图是否反映新分布。
