用嵌套可更新视图对比 LOCAL 与 CASCADED 对写入条件的检查范围

我在给报表写入入口加视图约束时，最容易误判的不是 WITH CHECK OPTION 本身，而是嵌套视图到底要检查几层。结论可以先记住：外层写 LOCAL，默认只给当前视图追加检查；写 CASCADED，则会把检查范围继续带到底层视图。若省略关键字，MySQL 默认按 CASCADED 处理。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/view-check-option.html

在嵌套可更新视图中，先看底层视图是否已经有自己的检查规则，再决定 LOCAL 还是 CASCADED。LOCAL 不是“永远跳过底层”，CASCADED 也不是改变视图定义；它们改变的是这次写入的检查范围。

先把“当前条件”和“底层条件”拆开

为了看清差异，下面用订单表做一个很小的例子。内层视图只暴露已支付订单，外层视图再限制订单日期。关键是：第一组内层视图故意不声明 WITH CHECK OPTION，这样才会把 LOCAL 与 CASCADED 的新增范围分离出来。

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    status VARCHAR(20) NOT NULL,
    created_at DATE NOT NULL,
    amount DECIMAL(10, 2) NOT NULL
);

-- 内层只负责暴露已支付订单，暂时不把 status 条件锁成写入规则。
CREATE VIEW v_paid AS
SELECT id, status, created_at, amount
FROM orders
WHERE status = 'paid';

-- 两个外层视图使用同一日期条件，只改变检查范围关键字。
CREATE VIEW v_recent_local AS
SELECT id, status, created_at, amount
FROM v_paid
WHERE created_at >= '2026-01-01'
WITH LOCAL CHECK OPTION;

CREATE VIEW v_recent_cascaded AS
SELECT id, status, created_at, amount
FROM v_paid
WHERE created_at >= '2026-01-01'
WITH CASCADED CHECK OPTION;

这组定义表达了两个独立条件：当前外层条件是 created_at >= '2026-01-01'，底层内层条件是 status = 'paid'。两种视图都需要保持一对一的行关系，才能作为可更新视图使用；本文只比较检查选项，不展开视图合并算法。

LOCAL：只把当前视图的条件作为新增边界

通过 v_recent_local 写入时，MySQL 先检查外层视图的日期条件。由于 v_paid 自己没有声明检查选项，LOCAL 不会替它临时追加级联检查。因此下面的行满足日期条件，却不满足内层的支付状态条件：

-- 这条写入满足外层日期条件，但 status 不是内层视图的可见条件。
INSERT INTO v_recent_local (id, status, created_at, amount)
VALUES (101, 'pending', '2026-02-10', 88.00);

-- 通过外层视图查询时，这行不会出现在 v_paid/v_recent_local 中。
SELECT id, status, created_at, amount
FROM orders
WHERE id = 101;

这个结果经常让人觉得“检查失效了”。其实检查只对当前视图负责：created_at 满足要求，写入就通过。行已经进入基表，但随后不再满足 v_paid 的可见条件。对写入入口来说，这是一种有意的“当前视图约束”，代价是数据可能被写入后从当前视图消失。

CASCADED：把整条视图链当成一个写入边界

换成 v_recent_cascaded 后，同样的日期条件仍会先检查，但 MySQL 还会递归到底层视图，并按级联方式检查 status = 'paid'。所以同一条 pending 写入会被拒绝：

-- 外层日期条件满足，但级联检查发现内层要求 status = 'paid'。
INSERT INTO v_recent_cascaded (id, status, created_at, amount)
VALUES (102, 'pending', '2026-02-10', 88.00);

-- 典型结果是 CHECK OPTION failed；具体错误文本以服务器返回为准。
-- 正确做法是让写入值同时满足两层视图条件。
INSERT INTO v_recent_cascaded (id, status, created_at, amount)
VALUES (103, 'paid', '2026-02-10', 88.00);

这就是两者在“底层视图没有自己的 CHECK OPTION”时最直观的区别：LOCAL 只守住外层日期，CASCADED 还守住内层支付状态。它们都不会把条件改写成新的视图定义，只影响 INSERT 或 UPDATE 是否能穿过这条视图链。

底层已经有检查规则时，LOCAL 也不会无视它

上面的差异依赖于 v_paid 没有自己的检查选项。如果把内层视图改成下面这样，内层已经声明了自己的 WITH CHECK OPTION：

-- 内层自己声明约束后，status 条件成为它固有的写入规则。
CREATE OR REPLACE VIEW v_paid_locked AS
SELECT id, status, created_at, amount
FROM orders
WHERE status = 'paid'
WITH CHECK OPTION;

-- LOCAL 仍只新增外层日期检查，但递归到 v_paid_locked 时要遵循它已有的规则。
CREATE OR REPLACE VIEW v_recent_local_locked AS
SELECT id, status, created_at, amount
FROM v_paid_locked
WHERE created_at >= '2026-01-01'
WITH LOCAL CHECK OPTION;

此时通过 v_recent_local_locked 写入 status = 'pending'，仍然会在内层规则处失败。这里要区分两句话：LOCAL 不会给底层无规则的视图强行加上级联检查；LOCAL 也不会删除底层已经声明的检查。MySQL 会递归处理底层视图，各层按照自身是否有检查选项以及当前检查模式共同决定结果。

UPDATE 更容易暴露检查范围

INSERT 只需要看新行是否满足条件，UPDATE 则常见“原来可见，修改后消失”的情况。例如订单已经是 paid，但把日期改到外层范围之外：

-- 这次修改会让行离开外层日期视图，所以 LOCAL 和 CASCADED 都应拒绝。
UPDATE v_recent_local
SET created_at = '2025-12-31'
WHERE id = 103;

-- 即使行原先可见，也不能通过更新把它改成视图不可见的状态。
UPDATE v_recent_cascaded
SET status = 'pending'
WHERE id = 103;

第二条在级联视图中还会触发内层的状态条件。排查“更新语句突然 CHECK OPTION failed”时，我会先问两个问题：修改后是否仍满足当前视图的 WHERE，以及底层视图是否有自己的检查选项或被外层 CASCADED 纳入检查。这样比只盯着 SQL 错误文本更快。

选择哪一种：看约束责任是否应该向下传递

我的判断标准是“谁拥有这条约束”。如果内层视图代表不可绕过的数据边界，优先让它自己声明检查，外层再根据需求使用 CASCADED；如果外层只是给某个管理入口增加日期范围，且允许写入后不再出现在该入口，LOCAL 才更符合意图。

最后用四个问题做设计确认

1. 每一层视图是否真的是可更新视图，写入是否保持一对一行关系？
2. 当前视图的 WHERE 条件，是否必须在写入后仍然成立？
3. 底层视图是否已经声明 WITH CHECK OPTION，它的约束责任是否应保留？
4. 省略 LOCAL/CASCADED 是否会让维护者误以为没有级联检查？

把这四个问题写进视图设计说明，通常就能避免把 LOCAL 当成“忽略底层”、把 CASCADED 当成“改变查询结果”这两种误解。真正需要选择的不是一个关键字的长短，而是写入责任要停在当前视图，还是沿着嵌套关系继续传递。

LOCAL 和 CASCADED 可以同时存在于不同外层视图吗？

可以。它们是各自 CREATE VIEW 定义中的检查策略，不会改变内层视图的查询定义。为了降低维护误解，建议在视图名或注释中明确写出外层入口的约束意图。

省略关键字后会怎样？

在 MySQL 中省略 LOCAL 与 CASCADED 时，默认使用 CASCADED。如果团队需要局部约束，最好显式写出 WITH LOCAL CHECK OPTION，让代码审查时能直接看到边界。

为什么插入成功后从视图里查不到？

常见原因是外层使用 LOCAL，而底层视图没有自己的检查选项：新行满足外层条件，写入了基表，却不满足底层视图的筛选条件。此时应回看视图链，而不是只检查 INSERT 是否返回成功。