merge视图可更新而temptable不可更新，因merge将update语句与视图定义合并下推至基表执行，保留主键、索引和行锁上下文；temptable先生成无元数据的临时表，丧失写入能力，且一定只读。
MySQL 视图的 ALGORITHM 属性不是可选项，而是实际影响查询执行路径的关键开关；选错会导致无法更新、性能骤降甚至锁表现异常。
为什么 MERGE 视图能 UPDATE 而 TEMPTABLE 不能
MERGE 算法本质是 SQL 文本合并：执行 UPDATE v1 SET x=1 时，MySQL 会把视图定义和这条语句“拼”成一条完整 SQL，再下推到基表执行。TEMPTABLE 则先执行视图定义生成临时内存表（或磁盘表），再对这个中间结果操作——但临时表没有基表的主键/索引上下文，也不持有行锁信息，所以不允许写入。
- 只有
ALGORITHM = MERGE的视图才可能支持INSERT/UPDATE/DELETE（还需满足其他条件，如无聚合、单表、无计算列等） -
ALGORITHM = TEMPTABLE视图一定只读，哪怕它只查一个表 -
WITH CHECK OPTION只对 MERGE 视图生效，TEMPTABLE 下该子句被忽略
MERGE 被自动降级为 TEMPTABLE 的常见触发点
即使你显式声明 ALGORITHM = MERGE，只要视图定义里出现以下任一结构，MySQL 就会静默改用 TEMPTABLE（并可能发 warning）：
- 含
COUNT()、SUM()、AVG()等聚合函数 - 含
DISTINCT或GROUP BY - 含
UNION或UNION ALL - 含子查询（尤其在
SELECT列表或WHERE中） - 视图定义里没引用任何基表（比如
SELECT 1 AS a）
验证方式：执行 SHOW CREATE VIEW view_name，看输出中实际生效的 ALGORITHM 是什么，别信自己写的声明。
UNDEFINED 默认值的真实行为
ALGORITHM = UNDEFINED 不是“随便选”，而是由 MySQL 在创建时做一次静态判断：
- 若视图逻辑满足 MERGE 条件（一对一映射、无聚合等），就固化为 MERGE
- 否则直接设为 TEMPTABLE
- 它不会在每次查询时动态切换算法
这意味着：不显式指定 ALGORITHM 时，你其实放弃了控制权；而一旦基表结构变更（比如加了触发器或生成列），原先能用 MERGE 的视图也可能在后续 ALTER VIEW 时被强制切到 TEMPTABLE。
性能与锁表现差异直击痛点
MERGE 查询走的是原表执行计划，能用上索引、能做条件下推、锁粒度就是基表行锁；TEMPTABLE 必须全量扫描基表生成临时结果，再过滤，索引基本失效，且整个过程可能持锁更久（尤其大结果集）。
- 测试发现：对千万级订单表建
WHERE status = 'paid'的 MERGE 视图，SELECT COUNT(*) FROM v_paid走索引覆盖，毫秒级；同逻辑用 TEMPTABLE，要扫全表再计数，秒级起跳 - 并发写入场景下，TEMPTABLE 视图查询可能加剧基表的
read lock竞争，因为它的执行路径更重 -
EXPLAIN查看执行计划时，MERGE 视图会展开为基表操作，TEMPTABLE 则显示derived表类型
真正容易被忽略的点是：ALGORITHM 一旦固化，就不会随查询条件变化而优化——哪怕你只查视图里的一小部分数据，TEMPTABLE 仍要先生成全部中间结果。
