窗口函数使视图不可更新，因其输出为派生值，无法映射到基表具体行与列；sql server语法层拦截，postgresql执行时报错，mysql直接判定只读。
窗口函数让视图失去“行到行”的映射能力
数据库执行 UPDATE 时，必须能精确锁定基表中**某一行、某一列**去修改。而窗口函数（如 ROW_NUMBER()、RANK()、SUM() OVER ()）输出的是基于排序/分区计算出的派生值，它不对应任何物理存储位置。视图一旦包含这类列，数据库就无法把 SET rank = 5 这样的操作翻译成“改哪张表的哪个字段”，直接拒绝更新。
SQL Server 和 PostgreSQL 报错但原因不同
SQL Server 会明确报错：Windowed functions can only appear in the SELECT or ORDER BY clauses —— 这是语法层硬限制，连解析都过不去；PostgreSQL 虽不拦语法，但在执行 UPDATE 时抛出 ERROR: cannot update a view，因为它检测到视图定义里有不可映射的计算列。MySQL 则更早拦截：只要 SHOW CREATE VIEW 里出现窗口函数，就直接认定为只读视图，不给执行机会。
试图绕过窗口函数更新的常见失败路径
以下做法看似合理，实际都不可靠：
- 在
UPDATE ... FROM (SELECT ..., ROW_NUMBER() ...) AS x子查询里套窗口函数：SQL Server 不允许子查询中带窗口函数用于 UPDATE；PostgreSQL 允许该写法但要求子查询可更新，而含窗口函数的子查询默认不可更新 - 用 CTE 包一层再 JOIN 更新：仅 SQL Server 支持这种模式，且 CTE 必须只引用单表、不含聚合、显式包含主键；PostgreSQL 和 MySQL 的 CTE 不参与 UPDATE 的可更新性判定，照样失败
- 把窗口函数结果存进临时表再关联更新：可行，但已脱离“更新视图”范畴，变成手动维护中间状态，容易漏同步或产生竞态
真正能落地的替代方案只有两个方向
要么放弃视图，直接对基表操作；要么把逻辑下沉：
- 用存储过程封装：输入参数（如
@customer_id），内部先算ROW_NUMBER() OVER (...) AS rn，再按rn 更新基表对应行 —— 所有数据库都支持 - 建物化视图（PostgreSQL 9.4+ / MySQL 8.0+ 用生成列+唯一索引模拟）：把窗口结果固化为真实列，确保该列在基表中存在且可写，再建普通视图引用它
最常被忽略的一点：即使你用 INSTEAD OF 触发器强行“支持”窗口视图的 UPDATE，触发器内部也得重算一遍窗口逻辑——这意味着每次更新都要全量扫描分区数据，性能代价远高于直写基表。
