MySQL 8.0视图性能提升源于MERGE算法更稳定启用，而非默认变快；其前提是视图定义避开聚合、子查询等强制降级为TEMPTABLE的结构，否则仍会静默退化且索引失效。
MySQL 8.0 视图性能提升不是“默认变快”，而是因为 MERGE 算法在更多场景下可被实际启用，且优化器对视图展开（view expansion）的支持更稳定——前提是你的视图定义没踩中那些强制降级的坑。
ALGORITHM = MERGE 在 MySQL 8.0 才真正可用
MySQL 5.7 及之前版本，ALGORITHM = UNDEFINED 几乎总是退化为 TEMPTABLE，哪怕视图只查单表、无聚合。这不是 bug，是设计限制：旧版优化器缺乏足够上下文判断是否安全合并。MySQL 8.0 重构了视图解析路径，只要满足条件，UNDEFINED 就能稳住 MERGE；显式声明 ALGORITHM = MERGE 的成功率也显著提高。
- 验证方式必须是
SHOW CREATE VIEW view_name，看输出里写的是ALGORITHM=MERGE还是悄悄变成了TEMPTABLE - 别信建表语句里写的
ALGORITHM = MERGE——如果定义含子查询或DISTINCT，MySQL 会静默改写，只发 warning（可能被客户端忽略） -
EXPLAIN SELECT * FROM v1 WHERE id = 123中若type是ref或const，说明条件已下推到基表并用了索引；若是ALL，基本就是TEMPTABLE在干活
MERGE 能下推 WHERE，TEMPTABLE 不能
这是性能差异的核心。MERGE 不生成中间结果，而是把外层查询的 WHERE、ORDER BY、LIMIT 直接“塞进”视图原始 SQL 里重写执行；TEMPTABLE 必须先全量扫描基表生成临时结果，再对临时表过滤——索引完全失效，数据量一过百万就明显卡顿。
- 坏例子：
CREATE VIEW v_orders AS SELECT * FROM orders WHERE status = 'shipped'—— 视图里自带WHERE，外层再加WHERE created_at > '2024-01-01'，MERGE仍可下推，但TEMPTABLE会先扫出全部已发货订单，再筛时间 - 好做法：视图只做字段投影和简单 JOIN，过滤逻辑留给调用方；例如
CREATE VIEW v_orders_basic AS SELECT id, user_id, amount FROM orders -
WITH CHECK OPTION只对MERGE生效，TEMPTABLE下该子句被直接忽略——这也是个快速判断算法是否生效的侧写点
MySQL 8.0 默认参数让 TEMPTABLE 更“贵”了
MySQL 8.0.16+ 把临时表默认引擎从 MEMORY 换成 TempTable，表面是增强稳定性，实则放大了 TEMPTABLE 视图的开销：它不再只是内存分配问题，还涉及 mmap 内存池管理、按页落盘、磁盘 I/O 等新维度。
-
temptable_max_ram控制内存上限（默认 1GB），超限后不是报错，而是悄悄写磁盘临时文件，监控上难察觉但延迟飙升 -
tmp_table_size和max_heap_table_size对TempTable引擎**不直接生效**，仅间接影响其内存分配策略；误调这两个值根本压不住物化开销 - 用
SELECT @@internal_tmp_mem_storage_engine确认当前默认临时表引擎，避免凭经验假设还是MEMORY
真正决定视图快不快的，从来不是 MySQL 版本号，而是你写的那条 SELECT 语句有没有触发 MERGE 的所有前提条件——少一个聚合、少一个子查询、少一个 GROUP BY，就多一分下推成功的可能。而一旦掉进 TEMPTABLE，再多的硬件资源也救不了全表扫描的命。
