MySQL事务与视图底层机制：从InnoDB隔离级别到可更新视图实战解析

很多人把 MySQL 的事务和视图拆成两个孤立知识点：事务就是 BEGIN / COMMIT，视图就是“给查询起个别名”。我从实际接手一个财务对账系统时才发现，这两个概念一旦“凑”在一起，会触发很多看似玄学的问题：一个后台统计任务在半夜跑出来对不上的汇总数，前一天还能正常更新的视图，第二天同事突然说插入数据被静默吞掉了。这些问题背后不是 SQL 写错了，而是把事务的可见性、隔离级别、提交时刻和视图的虚拟表特性搞混了。

这篇文章不讲面试题式的概念罗列，我会从一条 UPDATE 在 InnoDB 里的真实流转开始，把事务的回滚日志、隔离级别、锁与长事务逐个拆开，再切到视图的合并、物化和可更新约束上。适合正在排查一致性问题的后端开发，也适合刚把 MySQL 8 用起来、想真正理解 InnoDB 行为的 DBA 新人。

1. 从一次对不上账的统计任务，看事务必须守住的边界

1.1 一个教科书案例暴露出的问题

假设我们有这样一张账户表：

sql复制CREATE TABLE account (
    id INT PRIMARY KEY,
    user_id INT NOT NULL,
    balance DECIMAL(12,2) NOT NULL,
    updated_at DATETIME
) ENGINE=InnoDB;

业务需求是用户 A 给用户 B 转账 100 元。很多人会把两段 UPDATE 塞进同一个事务里：

sql复制START TRANSACTION;

UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 5;

COMMIT;

这是正确的做法。但正确不代表你理解了它为什么正确。你去看 MySQL 的官方文档，事务的 ACID 特性写得很优雅：原子性、一致性、隔离性、持久性。可真到生产环境，我见过太多“伪事务”写法：

• 把耗时很长的远程调用放在事务里，导致行锁长时间不释放；
• 在 REPEATABLE READ 级别下，同一个事务内部用两个连接去读数据；
• 统计报表在事务外多次 SELECT，中间别的会话提交了改动，最后把不同时刻的数据拼在一起，算出了莫名奇妙的汇总。

账户表那个转账例子，真正要说明的第一条红线是：事务里所有语句都成功，才算整体成功；只要有一条失败，前面已经执行成功的语句也必须被撤销。 这是原子性。数据库不是靠“你记得写 ROLLBACK”来保证的，是靠日志和加锁机制兜底。你要是不小心在两条 UPDATE 之间写了一句 SELECT SLEEP(5)，事务照样能提交，但那 5 秒内相关行可能被一堆查询堵住。

更隐蔽的是触发器、外键约束、生成列这类隐式操作。你以为事务里只改了一张表，实际上 MySQL 可能还改了系统表、更新了二级索引，或者级联触发了另一个表的 UPDATE。只要任何一个隐含步骤报错，整个事务就必须回滚。这也是为什么我把事务红线放在第一位：你必须把“可回滚”理解成数据库帮你自动协调所有相关修改，而不是你自己拼凑几条 SQL。

1.2 一致性不是数据库单方面的事

第二条红线是“一致性”。数据库的一致性并不是指它自动判断你的业务余额是否够扣，而是指：如果事务提交前数据库处于某种合法状态，事务提交后也必须处于另一种合法状态。这个合法，更多要靠业务约束、外键、检查约束、唯一索引去定义。

一个很典型的场景：你在事务里先插入一条订单，再更新库存表，最后往消息表里写一条“发送通知”。如果中间某一步违反唯一索引，整个事务回滚，订单插入也被撤销。这时一致性体现在“数据库没有留下半个订单”，而不是“库存数量一定正确”。库存数量到底对不对，MySQL 不知道。

所以你在设计事务时，必须把业务不变式写进数据库约束里。比如库存不能为负数，不要只靠代码判断，要在表里加 CHECK (stock >= 0)，或者用 InnoDB 的行锁把并发扣减串行化。事务不能替你判断业务规则，它只负责把一组规则作为一个整体落地。如果业务规则没写清楚，再强的事务也护不住数据。

1.3 持久性和提交点

第三条红线是持久性。InnoDB 的默认行为是，只要事务 COMMIT 成功，你就能放心地认为数据不会因为进程崩溃而丢失。这是因为事务在提交时，会先把对应的 redo log 刷到磁盘。这个内容我放在下一章展开，这里我想先强调一个使用层面的问题：如果你的业务框架里把 COMMIT 放在了网络回调之后，或者等另一个服务返回之后才提交，那这个事务的“持久性承诺”就开始得比业务实际发生晚。中间进程崩溃，用户那边看到转账成功，数据库里却没有记录，因为 COMMIT 还没执行完。

我见过不少项目把 @Transactional 注解加在 Controller 层方法上，整个方法包含远程 HTTP 调用、文件上传、等待第三方回调。这不是 MySQL 本身能解决的，你只能把事务边界尽量收敛到本地数据库操作的最小集合内。凡是跨越进程的不可控操作，都不应该被包在一个数据库事务里。

2. 一条 UPDATE 在 InnoDB 中到底经历了什么

2.1 Binlog、Redo Log 和内存页，谁先落盘

理解事务不能只看 SQL 层。InnoDB 为了提高吞吐，不会每改一行就立刻把数据页写回磁盘，而是先把数据页缓存在 buffer pool 里。那你可能会问：如果数据还在内存，COMMIT 凭什么说数据持久了？答案是 redo log。

可以这样理解 redo log：它是“物理变化”的流水账。InnoDB 会把磁盘上一个数据页的修改，比如“第 5 页偏移量 100 处写入值 123”，按照 append-only 的形式记录到 redo log buffer，事务提交时再把这一段日志刷到磁盘。万一数据库崩溃，重启后 InnoDB 可以根据 redo log 把丢失的修改重放出来。

所以在 InnoDB 里，真正的提交点不是数据页写入完成，而是 redo log 刷盘完成。只要 redo log 落盘了这一事务的重做记录，数据就算承诺持久了。至于数据页本身，可能过一会儿才由后台线程慢慢刷到磁盘，这叫脏页刷盘。

很多调优参数都是围绕“什么时候刷 redo log”设计的。比如 innodb_flush_log_at_trx_commit 参数：

如果项目对数据丢失极其敏感，innodb_flush_log_at_trx_commit=1 是必须的。你拿它和 sync_binlog=1 一起配合，才能让 binlog 和 redo log 在崩溃恢复时保持协调，不会出现“binlog 里记录了，但 InnoDB 数据页没有”这种主从不一致。

2.2 Undo Log 如何支撑回滚

redo log 解决的是“万一崩溃了怎么重放”，undo log 解决的是“事务还没提交，我想反悔怎么办”。这是两个方向相反的日志：redo 可以往前补数据，undo 可以往后倒数据。

InnoDB 表中的每一行，除了用户定义的字段，还藏着几个隐藏字段，其中最重要的是 DB_TRX_ID 和 DB_ROLL_PTR。DB_TRX_ID 记录最近一次修改这行的事务 ID，DB_ROLL_PTR 则指向 undo log 中的旧版本记录。

当你执行：

sql复制UPDATE account SET balance = balance - 100 WHERE id = 1;

InnoDB 在事务内先把该行的当前版本转成一条 undo 记录，保存修改前的值，再把数据页上这行改成新值，并让 DB_ROLL_PTR 指向刚生成的 undo 记录。如果事务回滚，InnoDB 就沿着这条 undo 链把旧值恢复回去。

更妙的是，这个 undo 链不仅服务回滚，还服务 MVCC（多版本并发控制）。一个干净的 REPEATABLE READ 事务在读取某一行时，会根据当前事务的快照信息判断该行版本是否可见，如果不可见，它会通过 DB_ROLL_PTR 找到更早的版本继续判断。所以你并不需要给历史版本建一张独立的历史表，InnoDB 用 undo log 就实现了“同一行数据在不同事务眼里版本不同”。

一个容易忽略的坑是：长事务会拖着很长的 undo 链不释放。事务长时间不提交，它看到的旧版本必须一直保留，那些早期版本对应的 undo 页也就不能删除。于是你会在监控里看到 undo 表空间越来越大。这时候即使你删数据、清表，空间也可能迟迟下不来。短事务不只是为了避免锁等待，同样是为了让 undo log 及时清理。

2.3 崩溃恢复时要分清楚“已提交”和“未提交”

在 MySQL 崩溃重启后，InnoDB 的恢复流程大体是：先扫描 redo log，把崩溃前已经写入 redo log 的变更尽量重放到数据页上。这里有一个关键原则：重放 redo log 时，它不会区分事务是否已经提交，因为 redo log 本质是物理页的变更记录，它只负责把数据页恢复到崩溃那一刻的样子。

数据页恢复好以后，InnoDB 再看 undo log，把所有“处于未提交状态”的事务标记为回滚。MySQL 重启后的回滚动作是后台逐步进行的，所以事务很多很大的场景下，你会在实例刚启动时看到一些临时表或回滚操作，这很正常。不要一看到 ROLLING BACK 就以为出故障了。

那 binlog 在崩溃恢复里扮演什么角色呢？binlog 是 MySQL Server 层记录的逻辑日志，redo log 是 InnoDB 引擎层记录的物理页日志。两者要配合，是因为主从复制依赖 binlog，而数据是否提交依赖 redo log。两个日志必须有一个共同的事务序号，否则可能出现在主库上事务已提交但 binlog 没写完整，从库重新执行时和数据对不上。MySQL 内部用两阶段提交来协调：事务提交时先写 binlog，再写 redo log。崩在中间某个节点，重启后会有相应的恢复判断。

3. 别高估 REPEATABLE READ，也别低估快照读

3.1 四种隔离级别在业务上的具体差异

MySQL 默认隔离级别是 REPEATABLE READ，注意这和很多数据库默认的 READ COMMITTED 不一样。你只要不显式改，建库建表后默认就是 RR。

隔离级别解决的是并发事务之间能读到什么数据的问题，有一个现成的标准分级：

“脏读”是读到别的事务还没提交的数据，这个基本没人会用 READ UNCOMMITTED。“不可重复读”指同一事务内两次读取同一行，结果不一样，因为中间有另一个事务提交了修改。“幻读”则是指两次范围查询，中间另一个事务插入了新行，导致第二次查询多出一些行。

我经常看到有人把 MySQL 的 RR 级别说成“完全消灭幻读”，这在 InnoDB 里并不完全准确。MVCC 的快照读确实解决了同一个 SELECT 多次读取的不一致问题，但如果你在 RR 下先使用快照读，再用 SELECT ... FOR UPDATE 这类锁定读，锁读取看到的是最新已提交版本，两者读到的东西可能不一样，这种现象往往也被归入幻读的讨论范畴。

InnoDB 真正用来对付幻读的武器是 next-key lock，也就是记录锁加间隙锁。范围查询会锁住扫描到的行，还会锁住行与行之间的间隙，防止其他事务往这个范围里插入新行。这个锁策略同样需要付出代价：并发插入冲突变多，死锁概率上升。所以很多并发量大的系统会把隔离级别调到 READ COMMITTED，让范围查询只锁行，不锁间隙，达到更高并发。代价是同一个事务里多次读取同一批数据可能结果不同。

3.2 为什么“先开事务再查询”并不能全局锁定

一个统计任务常见的错误写法是这样的：

sql复制START TRANSACTION;
SELECT SUM(balance) FROM account WHERE status = 1;
SELECT COUNT(*) FROM user WHERE created_at >= '2024-01-01';
COMMIT;

在默认 RR 级别下，第一条 SELECT 执行时，InnoDB 会为这个事务创建一致性快照。这个快照不是数据库某一刻全量数据的物理备份，而是一个基于版本号的“可见性规则”。此后事务内的普通 SELECT 都按照这个快照版本去判断行是否可见。

如果第二条 SELECT 涉及的表和第一条不一样，你可能会产生疑问：快照到底在什么时刻统一？答案是第一条普通一致性读的瞬间。事务开启本身不产生快照，只有第一次读取才真正把快照的起点钉住。如果两条 SELECT 之间别的会话提交了数据，事务内部快照建立得晚的事务，可能读到第二条 SELECT 的新数据，造成同一事务内部来自不同时间点的统计拼接。

如果你的业务就是要让整个报表看到同一点的数据，可以这样做：

sql复制START TRANSACTION WITH CONSISTENT SNAPSHOT;
SELECT SUM(balance) FROM account WHERE status = 1;
SELECT COUNT(*) FROM user WHERE created_at >= '2024-01-01';
COMMIT;

WITH CONSISTENT SNAPSHOT 会在事务一开始就为所有 InnoDB 表建立一个统一的一致性读视图。注意，这个语法不能保证 MyISAM 表的一致性，InnoDB 已经普及很多年了，但你仍可能遇到系统表或者临时表用的是其他存储引擎。所以不要只在脑子里记得这个语法，还要确认关联表都是 InnoDB，否则统计结果照样可能偏离。

3.3 当前读与锁定读的边界

普通 SELECT 在 MVCC 下是快照读，不加锁。但如果你写的是：

sql复制SELECT * FROM account WHERE id = 1 FOR UPDATE;
SELECT * FROM account WHERE id > 100 LOCK IN SHARE MODE;

这就变成了当前读，需要读取最新已提交版本，并且对命中的行加锁。在很多订单状态机应用里，SELECT ... FOR UPDATE 是防止并发重复处理的兜底手段。两条并发事务同时去锁同一个订单，只有一条能拿到锁，另一条只能等待。

但当前读会绕过 MVCC，由此带来一个很常见的“事务内看到两种结果”问题。在 RR 级别下，你先执行普通 SELECT，看到的是事务开始时的旧版本。接着执行 SELECT ... FOR UPDATE，由于要加锁，它不会使用旧快照，而是直接看最新版本，于是一行数据在同一个事务内拿到了不同内容。这不是 MySQL bug，而是当前读的本质。

事务里如果要做“先查再改”的操作，我建议你第一步就直接用当前读加锁。比如库存扣减，直接 SELECT stock FROM product WHERE id = 1 FOR UPDATE，再判断库存是否充足，然后再 UPDATE。如果你先普通 SELECT，再 UPDATE，中间可能出现两个事务同时拿到库存充足，然后一起减去库存，最终把库存扣成负数。这就是典型的并发超卖场景。

4. 长事务、锁等待和跨库一致性的实战处理

4.1 抓到“罪魁祸首”的排查 SQL

长事务的危害不仅是锁别人，还包括 undo 膨胀、主从延迟、连接池被占满。很多开发者感觉系统卡了，第一反应先去查慢查询日志，结果慢查询日志里一条都没慢，因为真正的问题不是一个 SQL 慢，而是一个已经开了几小时的事务一直握着锁，其他正常 SQL 都在等锁。

我常用的排查 SQL 是查 information_schema.innodb_trx：

sql复制SELECT trx_id,
       trx_state,
       trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_running_seconds,
       trx_mysql_thread_id,
       trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started ASC;

trx_started 一旦距离当前时间很长，就要立刻定位这个事务所属的连接。再看它锁了哪些表、哪些行，可以用 performance_schema.data_locks 和 sys.innodb_lock_waits 来查。MySQL 8.0 里 performance_schema 默认开启，我推荐直接用：

sql复制SELECT *
FROM sys.innodb_lock_waits;

这个视图会直接告诉你谁在等待锁，谁持有锁，等待了多久。如果发现持有锁的是一个开发环境遗留的调试会话，直接 KILL 对应的线程 ID 往往是最快的止血方式。

4.2 被事务注解“包装”过度的代码

Java 生态里最常见的坑，是把 @Transactional 加在没有必要的方法上，或者加在 public 方法上，但同类的内部方法调用不会触发代理，导致注解完全失效。这里不展开讲 Spring 代理机制，只说结论：

• @Transactional 最合理的粒度是 service 层里的一个本地数据库操作单元；
• 不能在事务里做耗时的 IO 操作，比如发短信、调第三方支付、下载文件；
• 如果方法是 private 或者同类内部调用，@Transactional 不会生效。

另外一个容易踩的点是事务传播行为。默认 REQUIRED 表示当前有事务就加入，没有就新建。如果你事务方法内部调了另一个有事务的方法，而且内部方法抛出的异常被外层 catch 掉了，事务可能不会按你预期回滚。Spring 默认只对 RuntimeException 回滚，checked exception 不会触发回滚，这也是很多人“明明加了事务，数据还是写进去了”的重要原因。

如果你只是想保证批处理中每几条数据单独提交，不要让一个大循环占一个事务，可以考虑按批次提交。比如一次处理一万条数据，每 200 条提交一次，这样即使某一段失败，也不会把前面几千条全部回滚，更不会把数据库连接长时间占着不放。

4.3 订单和库存这类跨系统一致性怎么办

当订单服务和库存服务不在同一个数据库里，MySQL 单库事务就管不住了。这是一个典型的分布式一致性问题。业界有 XA 两阶段提交、TCC 补偿、Saga、本地消息表等思路。不要一上来就追求强一致中间件，很多时候用本地消息表或者事务发件箱模式更稳。

大致的思路是这样的：订单库和库存库都可以有自己的事务。你先把订单写入订单库，同时往订单库里的一张 outbox 表写入一条“待发送的库存扣减事件”，这两者放在同一个本地事务中提交。然后一个后台任务扫描 outbox 表，把事件投递到消息队列或者直接调用库存服务。库存服务消费成功后，再回调订单服务，把 outbox 记录标记为已处理。

这套方案的好处是：本地事务保证订单和事件不会出现“订单有了、事件丢了”的情况。哪怕消息队列暂时不可用，事件也还躺在 outbox 表里，可以不断重试。对比 XA 的强同步方案，它更轻量，也更容易处理网络抖动。代价是你需要接受最终一致性：从订单提交到库存扣减完成，中间有一个短暂的不一致窗口。

如果业务要求必须在同一笔交易里同时看到库存扣减和订单生成，那只能引入分布式事务协调器，或者干脆把订单库和库存库放在同一个 MySQL 实例里，用同一个本地事务解决。很多时候不是技术做不到分布式强一致，而是把表和库拆分得过早，导致本地事务可以解决的事被强行变成了跨库问题。

5. MySQL 视图的底层逻辑：它不缓存结果，但可以做很多事

5.1 视图到底是什么

MySQL 的视图本质上是一个“虚拟表”，它的数据不单独存储，而是在查询视图时动态从基表读取。你可以把创建视图想象成把一段 SELECT 语句存起来，之后对视图的查询会被数据库重新解析并执行。

创建视图的语法很直接：

sql复制CREATE VIEW order_summary_v AS
SELECT o.order_id,
       o.user_id,
       SUM(i.amount) AS total_amount,
       COUNT(i.id) AS item_count
FROM orders o
LEFT JOIN order_items i ON i.order_id = o.order_id
GROUP BY o.order_id, o.user_id;

创建之后，你就能像查询表一样查它：

sql复制SELECT * FROM order_summary_v WHERE order_id = 1001;

但这个 WHERE order_id = 1001 到底能不能直接压到 orders 表上走索引，取决于 MySQL 优化器如何对待这个视图。MySQL 对视图主要有两种执行策略：merge（合并）和 temptable（物化临时表）。你可以在创建时指定算法：

sql复制CREATE ALGORITHM = MERGE VIEW v_order AS SELECT ...;
CREATE ALGORITHM = TEMPTABLE VIEW v_order AS SELECT ...;

如果用了 MERGE，MySQL 会把视图定义直接合并进外部查询，相当于你在写原生 SQL。这样往往有机会利用基表索引。如果用了 TEMPTABLE，MySQL 会先执行视图内部的 SELECT，把结果存在临时表里，再对外部查询使用。聚合查询、DISTINCT、GROUP BY、LIMIT 这类结构在很多情况下会让 MySQL 无法用 merge，只能临时物化视图结果。

5.2 视图能加快查询速度吗

这个问题的答案很明确：视图本身不能加快查询速度，它只会让你写 SQL 更方便。 网上流传“通过视图查询更快”的说法，大多数是把 Oracle 物化视图和普通视图搞混了。MySQL 原生的普通视图没有预计算和缓存，你查一次它就执行一次对应的 SELECT。基表没索引，视图查询照样全表扫描；基表有联合索引，视图查询能不能用，还要看优化器能否把外部条件推到基表上去。

我见过这种低效用法：先建立一个只包含某几个字段的视图，以为这样能“屏蔽掉不用的字段，让数据量变小”。实际上视图查询时还是会访问基表，并不会因为只查询五个字段就减少扫描的数据页数量。数据量是由 WHERE 条件和索引决定的，不是由 SELECT 字段列表决定的。

那有没有一种适合用视图加速的场景？少，但有一种：有些查询本身很复杂，你又希望把条件写给业务接口的调用方，视图合并优化后，外层条件能直接下推到基表走索引，业务方不用理解底层表结构。比如：

sql复制CREATE VIEW active_user_orders_v AS
SELECT id, user_id, amount, created_at
FROM orders
WHERE deleted = 0;

如果业务查询通常都带 user_id 条件，并且 orders 表上有 (user_id, created_at) 这样的索引，那么视图外部加 WHERE user_id = 123 时就可能走索引。这里给查询提速的不是“视图”这个抽象，而是那个 (user_id, created_at) 索引。

判断视图查询到底有没有下推条件，你可以使用：

sql复制EXPLAIN FORMAT=TREE SELECT * FROM active_user_orders_v WHERE user_id = 123;

EXPLAIN 输出会展示访问的是基表还是物化派生表，以及是否使用了索引。在做任何“视图到底快不快”的判断前，先跑一次 EXPLAIN，不要拍脑袋。

5.3 用视图做权限隔离的几种姿势

视图最有价值的使用场景其实是“安全隔离”。比如一张员工表里有薪资、手机号、身份证号，你不能让客服直接 SELECT 整张表，但可以建一个视图：

sql复制CREATE VIEW customer_service_staff_v AS
SELECT id, name, department, hire_date
FROM staff
WHERE status = 1;

再通过授权让客服账号只能查视图：

sql复制GRANT SELECT ON hr.customer_service_staff_v TO 'cs_user'@'%';

如果视图定义时使用默认的 SQL SECURITY DEFINER，那么调用视图的用户只需要有视图本身的权限，不需要有底层表的权限。这个机制能很好地控制列的暴露范围。

有些系统还会用视图做行级权限，比如不同城市的销售想看不同城市的数据。底层表不加过滤条件，但建视图时强制加 WHERE city_id = ...，然后给不同的应用账号建不同的视图。这个做法可用，但要小心视图定义中不要硬编码敏感条件，否则权限模型会非常僵硬。相比真正完整的行级安全策略，MySQL 视图只能算一种轻量方案。

6. 可更新视图、安全检查选项和那些容易踩的规则

6.1 可更新视图不是所有视图都能改

很多开发者以为视图只能 SELECT，实际上 MySQL 允许你对某些简单视图执行 INSERT、UPDATE、DELETE。能被更新的视图，必须满足一些条件：

• 视图中的每一行都能对应基表里唯一的物理行；
• 视图不能包含聚合函数、GROUP BY、DISTINCT、HAVING、UNION 等会产生“去重结果”的语句；
• 视图不能包含子查询（某些条件下可以，但依赖具体版本）；
• 视图中的字段必须直接来自基表列，而不是表达式或函数结果。

所以什么时候视图会变成不可更新？最典型的就是前面那个 order_summary_v，它用了 JOIN、GROUP BY、SUM、COUNT，MySQL 无法确定 UPDATE 哪一行，自然不允许修改。

一个简单可更新视图的例子：

sql复制CREATE VIEW account_basic_v AS
SELECT id, user_id, balance, status
FROM account
WHERE status = 'active';

然后你可以执行：

sql复制UPDATE account_basic_v SET balance = balance - 10 WHERE id = 1;

这本质上会更新底层 account 表。这里要特别小心：如果这个 UPDATE 把某行改得不再满足视图的 WHERE status = 'active'，那么这行就会从视图里“消失”。这种更新本身合法，但会造成应用层逻辑困惑，所以 MySQL 提供了 WITH CHECK OPTION 来约束更新或插入的行必须满足视图定义条件。

6.2 LOCAL 和 CASCADED 检查的作用域区别

当你写 WITH CHECK OPTION 时，可以带 LOCAL 或 CASCADED 关键字。很多人看见这两个词就晕，我尽量用一句话解释：

• WITH CASCADED CHECK OPTION：更新或插入时，不仅检查当前视图的 WHERE 条件，还会检查这个视图依赖的所有上游视图的 WHERE 条件；
• WITH LOCAL CHECK OPTION：主要检查当前视图自己的 WHERE 条件，对上游视图的限制没有那么严格。

为了看出差别，可以看一个抽象例子。

先建一张基础表：

sql复制CREATE TABLE t_user (
    id INT PRIMARY KEY,
    name VARCHAR(20),
    level INT
);

创建基础视图 v_level_low，过滤低等级用户，但不加检查选项：

sql复制CREATE VIEW v_level_low AS
SELECT id, name, level FROM t_user WHERE level < 3;

再创建子视图 v_high_potential，只保留部分用户，并加上检查选项：

sql复制CREATE VIEW v_high_potential AS
SELECT id, name, level FROM v_level_low WHERE id > 100
WITH LOCAL CHECK OPTION;

你执行：

sql复制INSERT INTO v_