视图查询通常不比直接JOIN更高效，它只是语法糖，执行计划取决于展开后的SQL，且每次查询需重新解析优化；MySQL中MERGE算法性能接近手写JOIN，TEMPTABLE则更慢。
SELECT * FROM my_view 比直接写等价的多表 JOIN 更高效？基本不会——绝大多数情况下，视图查询更慢或至少不更快。它只是语法糖，不是性能优化手段。
视图查询和直接 JOIN 执行的是同一段 SQL
你创建视图时写的 CREATE VIEW v AS SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id，之后执行 SELECT * FROM v WHERE u.status = 'active'，数据库实际干的事是：先把视图定义展开，再合并外层条件，最终执行的还是类似 SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' 这条语句。
也就是说，执行计划、索引使用、驱动表选择，全都取决于展开后的完整 SQL，而不是“视图”这个壳子。
- 视图不存数据，不建索引（除非是物化视图），也不缓存执行计划
- 每次查询都要重新解析、重写、重优化，多一层开销
- 如果视图里写了
ORDER BY或LIMIT，反而会阻碍外层WHERE下推，导致先排序/截断再过滤
什么情况下你会觉得“视图更快”？其实是错觉
常见假象来源：
-
应用层缓存了结果：比如 ORM 或中间件对
SELECT * FROM v做了结果缓存，而对原始 JOIN 语句没缓存 -
视图定义里提前加了过滤条件：比如
CREATE VIEW active_orders AS ... WHERE o.status = 'paid'，而你查视图时没加额外条件，相当于天然缩小了数据集 - 开发环境数据量小 + 查询计划巧合稳定：小数据下差异不明显，且优化器偶然选了好路径，误以为是视图功劳
真正起作用的是“提前过滤”“索引覆盖”“驱动表合理”，不是视图本身。
MySQL 中视图算法影响性能表现
MySQL 支持两种视图算法：MERGE 和 TEMPTABLE。用 SHOW CREATE VIEW my_view 可查当前设置：
-
MERGE：默认，把视图 SQL 直接合并进主查询，行为最接近手写 JOIN -
TEMPTABLE：强制将视图结果物化成临时表，再对外层查询做筛选——这几乎总是更慢，尤其数据量大时
如果你发现视图比直接 JOIN 慢得多，第一件事就是检查是不是被 MySQL 自动设成了 TEMPTABLE（比如视图含聚合、子查询、DISTINCT 等）。
真正能提升多表联查效率的，是这些
别指望视图提速，盯住这几处：
- 确保
JOIN字段有索引，尤其是被驱动表的关联列（如orders.user_id） - 把过滤条件尽可能写进
ON子句或子查询里，而不是全堆在最后的WHERE - 避免在视图里写
SELECT *，外层再WHERE—— 这会让优化器难以下推条件 - 高频复杂报表类查询，考虑用
MATERIALIZED VIEW（PostgreSQL）或定时汇总表（MySQL）代替普通视图
视图的价值在可维护性、权限控制、接口统一，不在加速。把它当“SQL 函数”用，别当“性能开关”用。
