视图不能直接更新，因其无物理存储且涉及JOIN、聚合等时数据库无法唯一映射修改目标；INSTEAD OF触发器是唯一能接管该逻辑断点的机制，需显式处理每列映射与多表定位。
视图不能直接更新，不是因为数据库“不想支持”，而是它根本无法安全、唯一地推导出该更新应落在哪张基表的哪几列上——INSTEAD OF触发器不是补丁，是唯一能接管这个逻辑断点的机制。
普通视图 UPDATE 报错的根本原因
报错如 ERROR: cannot update a view 或 Can't update table 't1' in FROM clause，本质是数据库在语法解析阶段就拒绝了操作。因为：
- 视图没有物理存储，
UPDATE v SET x = 1并不对应任何磁盘行地址，引擎无从锁定或修改 - 若视图含
JOIN、GROUP BY、DISTINCT、UNION或计算列（如price * qty AS amount），数据库无法反向映射：改amount应调高price还是qty？删一行到底该删 orders 还是 customers？ - MySQL 完全禁止在视图上建任何 DML 触发器；PostgreSQL 和 SQL Server 虽允许
INSTEAD OF，但仅限于你手动写死全部逻辑——它不帮你“猜”，只给你一个入口。
INSTEAD OF 触发器为什么必须显式处理每一列
INSTEAD OF INSERT 不会自动把 INSERT INTO v (a,b,c) VALUES (1,2,3) 拆解并分发到基表；它只是拦截语句，把控制权交给你。常见翻车点：
- 漏写某列映射，比如视图投影了
user_id、name、status，但触发器里只INSERT INTO users (user_id, name)，status缺失且基表设了NOT NULL→ 直接失败 - 把视图里的计算列（如
full_name）当真实字段去插，而基表根本没有这列 - SQL Server 中用了
OUTPUT子句，但触发器没适配INSERTED表结构，报错：The target table 'xxx' of the DML statement cannot have any enabled triggers if the statement contains an OUTPUT clause - PostgreSQL 中函数返回类型不是
trigger，或没写RETURN NEW/RETURN NULL→ 触发器静默失效
UPDATE 和 DELETE 在多表视图中为何特别危险
视图的 WHERE 条件只作用于查询结果集，但基表更新必须精准定位。例如视图 v_orders_with_customer 基于 orders JOIN customers：
-
UPDATE v SET status = 'shipped' WHERE order_id = 123—— 这个order_id只在orders表中有意义，不能直接用于customers表的WHERE - 若触发器写成
UPDATE customers SET ... FROM INSERTED i JOIN orders o ON i.order_id = o.order_id，而一个客户有 5 个订单，就会意外更新客户表 5 行 -
DELETE FROM v WHERE order_id = 123时，必须决定：只删orders行？是否要级联删order_items？要不要检查orders.status = 'shipped'并抛错？这些全得手写，没有默认行为
别指望“可更新视图”自动兜底
所谓“可更新视图”只适用于极简场景：单表、无计算列、无聚合、无 JOIN。一旦视图定义里出现 LEFT JOIN 或 COALESCE(name, 'N/A')，PostgreSQL 就默认禁用更新，MySQL 更是直接报错。此时想绕开 INSTEAD OF，唯一替代是：
- 用存储过程封装所有写逻辑，应用层调用
CALL upsert_user_profile(...)而非直写视图 - 在所有被引用的基表上建
AFTER触发器，并靠会话变量（如current_setting('app.view_context')）识别是否来自视图操作——但这只能做审计，不能改变写行为
真正难的从来不是写触发器语法，而是厘清“这一行视图数据背后，到底牵动了几张表、哪些约束、哪些业务规则”。漏掉一个并发检查，或少判一种状态分支，上线后就是数据不一致。
