多表连接视图默认不支持DELETE，因数据库引擎无法安全确定删除哪张基表的哪行；ORA-01779、Msg 4405、ERROR 1351均源于此语义保护机制；仅单表、无计算、列完整、非只读视图才支持原生DELETE；多表场景必须用INSTEAD OF触发器手动分发删除逻辑并处理事务与约束。
多表连接视图默认不支持 DELETE，不是语法写错了，是数据库引擎根本拒绝执行。
DELETE 报错 ORA-01779 / Msg 4405 / ERROR 1351 的真实原因
当你对一个含 JOIN 的视图执行 DELETE FROM v_orders，数据库不是“懒得实现”，而是明确判定：它无法安全推导出「该删哪张基表的哪几行」。比如视图定义是 SELECT u.name, o.order_id FROM users u JOIN orders o ON u.id = o.user_id，你删一行，数据库不知道该删 users 还是 orders，或者两者都删——这会破坏参照完整性或产生歧义。Oracle 报 ORA-01779，SQL Server 报 Msg 4405，MySQL 直接拒绝（视图不可更新），本质都是同一种语义保护机制。
哪些视图能直接 DELETE？必须同时满足这四条
只有单表、无计算、无约束缺失、未显式只读的视图才允许原生 DELETE：
- SELECT 源头只能是**一张基表**，不能有
JOIN、UNION、GROUP BY - 所有列必须是基表原始列，不能是表达式（如
UPPER(name)）、函数、ROWNUM或别名覆盖 - 基表所有
NOT NULL列都得出现在视图中（否则INSERT可能失败，有些系统连DELETE也一并禁用） - 创建时没加
WITH READ ONLY（Oracle）或等效限制
例如：CREATE VIEW emp_v AS SELECT emp_id, name, dept_id FROM employees; —— 这个可以 DELETE FROM emp_v WHERE emp_id = 101；但只要加个 JOIN departments d ON e.dept_id = d.id，立刻失效。
想对多表视图做 DELETE？绕不开 INSTEAD OF 触发器
这不是“高级技巧”，而是唯一合规路径。它不修改视图本身，而是在视图上挂一个 INSTEAD OF DELETE 触发器，把删除逻辑手动分发到各基表：
- 触发器内通过
:OLD（Oracle/PostgreSQL）或deleted表（SQL Server）拿到待删行的原始值 - 你必须自己写
DELETE FROM orders WHERE user_id = :OLD.user_id和DELETE FROM users WHERE id = :OLD.user_id（按业务规则决定删哪些） - 必须显式处理事务边界：要么全成功，要么全回滚；外键约束冲突要提前检查，不能依赖数据库自动报错后中断
- SQLite 也支持，但语法用
NEW/OLD；MySQL 不支持INSTEAD OF，只能改用存储过程封装
漏掉主键暴露、没处理级联删除、忽略外键依赖——这些都会让触发器在运行时报错，且错误信息往往指向基表而非视图，排查时容易走偏。
最容易被忽略的细节：WHERE 条件字段是否可索引
即使你写了正确的 INSTEAD OF DELETE，如果触发器里要根据视图某列（比如 user_email）去查基表，而该列在基表上没有索引，DELETE 就会变慢甚至锁表。视图本身不存数据，但它的 DELETE 行为最终落地为基表的物理操作——性能瓶颈永远在基表，不在视图定义里。
