CREATE VIEW 语句仅保存含JOIN的SELECT定义，不执行连接；真正联接发生在查询视图时，每次实时计算，支持逻辑封装、权限控制、易维护与无感升级，但需注意列名冲突、连接类型语义差异及性能影响。
CREATE VIEW 语句本身不执行联接，它只是把一个含 JOIN 的 SELECT 语句存为命名对象；真正发生联接是在你 SELECT 这个视图时——每次查询都实时执行底层的多表连接逻辑。
为什么用 JOIN 写视图而不是直接查表？
核心不是“能不能”，而是“要不要把连接逻辑固化下来”。比如你总要查订单+用户+商品三张表的组合信息，每次都写 LEFT JOIN 容易出错、难维护、SQL 膨胀。用视图封装后，业务代码里只写 SELECT * FROM order_user_item_view 就行。
- 避免重复书写相同
ON条件（如o.user_id = u.id），漏写或写错字段名会直接导致结果为空或笛卡尔积 - 权限控制更干净：DBA 可以只给用户查视图的权限，不开放基表，尤其适合隐藏敏感字段（比如把
u.phone排除在视图列外） - 后续加字段或改连接方式（比如从
INNER JOIN改成LEFT JOIN），只需改视图定义，所有调用方无感
LEFT JOIN 和 INNER JOIN 在视图里表现一样吗？
完全不一样，而且影响非常直接——它决定了视图返回的行数是否包含“缺失关联数据”的记录。
-
INNER JOIN视图：只返回所有参与表中都有匹配行的数据。比如users INNER JOIN orders，用户没下过单就不出现在视图里 -
LEFT JOIN视图：左表（FROM后面那个）每行都保留，右表没匹配上就补NULL。比如users LEFT JOIN orders，哪怕用户没下单，也会出现在视图里，order_id等字段为NULL - 别误以为“视图建好了就固定了连接语义”——删掉基表某条数据，视图查询结果立刻变化；它不是快照，是实时计算
创建多表联接视图时最容易踩的坑
不是语法报错，而是运行时行为不符合预期，往往几小时后才暴露。
- 列名冲突不处理：
SELECT * FROM a JOIN b ON a.id = b.a_id中如果两表都有id字段，视图定义能通过，但查询时SELECT id FROM view_name会报错 “Column 'id' in field list is ambiguous”。必须显式写列名或用别名，比如a.id AS user_id, b.id AS order_id - 忘记加
WHERE条件却以为视图自带过滤：视图只是封装SELECT，不带条件就是全量连接。想限制数据范围，得在视图定义里写死WHERE status = 'active'，或者留参数占位（MySQL 不支持参数化视图，得靠应用层拼接） - 嵌套太深导致性能骤降：三层以上
JOIN+GROUP BY+ 子查询的视图，每次查都会重算。不要为了“看起来简洁”把聚合逻辑也塞进视图，先确认基表有对应索引（比如ON字段、WHERE字段）
复杂点在于：视图不缓存结果，也不自动优化执行计划。它只是语法糖，背后还是那条原始 SQL。如果你发现查视图比直接写 JOIN 慢很多，别急着怪视图，先 EXPLAIN 看看实际走的是不是你期望的索引路径。
