视图中JOIN本身不慢，慢因视图未规避重复计算与无效扫描；每次查询均重执行全部JOIN及过滤，大表无WHERE易全表扫描，LEFT JOIN缺索引更易低效，嵌套视图阻碍谓词下推。
视图里用 JOIN 会变慢吗？取决于你怎么写
会，但不是因为用了 JOIN 本身，而是视图定义没避开执行时的重复计算和无效扫描。数据库不会“预物化”普通视图，每次查视图都重跑整个 SELECT，包括所有 JOIN 和过滤条件。
- 如果视图里
JOIN了大表但没加WHERE条件，查询时哪怕只取 1 行，也可能扫全表 -
LEFT JOIN比INNER JOIN更容易触发低效执行计划，尤其右表缺少索引时 - 嵌套视图（A 视图引用 B 视图，B 又含
JOIN）会让优化器更难推导谓词下推，常导致中间结果膨胀
CREATE VIEW 里哪些 JOIN 写法最伤性能
不是语法错，是逻辑设计让优化器无从下手。典型问题集中在连接键、过滤时机和冗余字段上。
- 用函数包装连接字段，比如
ON UPPER(t1.code) = UPPER(t2.code)：索引失效，强制全表比对 -
JOIN后才WHERE过滤大表，应把关键过滤条件尽量“下沉”到子查询或提前WHERE - 视图里
SELECT *拉回所有列，但调用方只用其中 2 列——IO 和网络开销白增，有些数据库连列裁剪都做不了 - 多层
JOIN且连接顺序不合理（如小表没放前面），优化器可能选错驱动表
怎么让带 JOIN 的视图跑得不比直接查慢多少
核心就一条：帮优化器在视图定义阶段就锁定可下推的过滤和可利用的索引路径。
- 连接字段必须是原始列，且两端类型一致、有索引（
t1.user_id和t2.user_id，别用CAST或CONCAT包一层） - 在视图定义里显式加上高频查询的过滤条件骨架，例如
WHERE t1.status = 'active'，即使调用方还会加其他条件，也能缩小初始数据集 - 用
EXPLAIN对着视图查一次，重点看rows和type字段——如果出现ALL或预估行数远超实际，说明JOIN路径没走索引 - PostgreSQL 用户可考虑
MATERIALIZED VIEW，但注意刷新延迟和锁行为；MySQL 8.0+ 支持基于直方图的优化，记得更新统计信息
视图 JOIN 出现 Using temporary; Using filesort 怎么办
这是 MySQL 执行计划里的红灯信号，意味着排序或分组被迫落盘，基本等于性能已崩。根源常在视图定义里隐藏的隐式排序或聚合。
- 检查视图 SQL 是否含
ORDER BY（视图里禁止写ORDER BY，除非配合LIMIT，否则会被忽略还拖慢） -
GROUP BY字段没被索引覆盖，或GROUP BY字段与JOIN键不一致，导致无法复用连接顺序 - 连接后字段参与
ORDER BY，但该字段不在任何连接表的索引里（例如ORDER BY t2.created_at，但t2表没建created_at索引） - 临时表大小超过
tmp_table_size，立刻降级为磁盘临时表——查SHOW VARIABLES LIKE 'tmp_table_size'，按需调大
复杂点在于，同一个视图在不同 WHERE 条件下执行计划可能完全不同，而你看到的 EXPLAIN 结果只是当前参数下的快照。别只测一个 case。
