根本原因是数据库无法将视图更新安全映射回单张基表的唯一行；只要含group by、聚合函数、distinct、多表join、子查询等，mysql/postgresql即判定不可更新。
SQL视图无法直接插入或更新数据，根本原因不是“数据库故意限制”，而是**数据库引擎无法安全、唯一地把你的 INSERT/UPDATE 操作映射回底层基表的某一行或某一列**。它本质上是个查询定义，不是物理存储结构。
视图定义含聚合、DISTINCT 或 GROUP BY 就一定不可写
这类视图破坏了“行对行”的映射关系：
-
SUM()、COUNT()、AVG()等聚合函数让多行变成一行，数据库不知道该把新值写到哪几行 -
DISTINCT可能隐藏重复行，UPDATE 时无法确定影响的是原始哪一条 -
GROUP BY同样把多行折叠，且分组键未必是基表主键，UPDATE 的WHERE条件无从生成
典型报错：View 'xxx' is not updatable（MySQL/PostgreSQL）或 The attempted insert or update failed（SQL Server）。
多表 JOIN 视图在绝大多数场景下不能直接写入
即使你只改其中一列，数据库也必须确认修改只影响一个基表，且不引发歧义：
- SQL Server 要求被更新的列必须全部来自同一个基表，且该表在
FROM子句中为“主导表” - MySQL 完全禁止对多表视图执行 INSERT，UPDATE 也仅限单表列，且不能同时更新多个表的字段
- PostgreSQL 允许更新第一个
FROM表，但需满足INSTEAD OF触发器或规则支持，否则静默拒绝
常见陷阱：视图里写了 LEFT JOIN departments d ON e.dept_id = d.id，你 UPDATE e.name 成功，但一试 d.dept_name 就报错 —— 不是因为语法错，是引擎判定“这个列不该由你通过视图碰”。
基表约束在背后悄悄拦截写入操作
视图本身不存数据，所有 INSERT/UPDATE 最终都落到基表，所以基表的约束会原样生效：
- INSERT 时提示
Column 'created_at' doesn't have a default value？说明视图没包含该列，但基表设了NOT NULL且无DEFAULT - UPDATE 某字段后查不到记录？可能是视图加了
WITH CHECK OPTION，而你的修改让行不再满足视图的WHERE条件（比如WHERE status = 'active'，你把它改成'inactive'） - 试图 INSERT 到计算列（如
price * qty AS amount）？数据库直接拒绝，因为基表根本没有amount这个字段
这类错误常被误判为“视图问题”，实际要查 DESCRIBE table_name 或 sp_help 'table_name' 看基表结构。
EF Core 映射视图后调用 SaveChanges() 没反应
这不是 bug，是设计使然 —— EF Core 默认把无主键类型当只读处理：
- 漏写
HasNoKey()：报错Unable to track an entity of type 'X' because it does not have a primary key - 只写
HasNoKey()不配ToView("xxx")：迁移会尝试建同名表，而不是指向视图 - 误加
HasKey(x => x.Id)：EF Core 生成带WHERE Id = @p0的 UPDATE，但视图没这列，结果Store update affected an unexpected number of rows (0)
真正能写的路径只有两条：context.Database.ExecuteSqlRaw() 手写 SQL，或封装进存储过程再调用 —— 别指望 Add()/Update() 自动生效。
最常被忽略的一点：可更新性不是“视图是否创建成功”的问题，而是“当前数据库版本 + 当前视图定义 + 当前基表结构 + 当前 SQL 语句写法”四者共同决定的。哪怕昨天能 UPDATE，今天给基表加了个 NOT NULL 字段，或视图里加了个 ISNULL(name, '')，就可能立刻失效。
