视图是持久化虚拟表，派生表是单次查询临时生成的子查询结果；视图需预先创建、支持权限控制与复用，派生表无需定义、仅限当前查询使用且必须带别名。

视图和派生表都用于封装查询逻辑，但存在本质差异：视图是持久化对象，派生表是单次查询内临时存在的子查询结果。选哪个，取决于你是否需要复用、权限控制或跨查询一致性。

什么时候必须用视图而不是派生表

当你需要多次调用同一复杂逻辑，或要配合权限管理时，只能用视图。

• 多个应用模块反复查询 “用户订单汇总（含商品名、下单时间、实付金额）”，建 order_summary_view 后，所有地方直接 SELECT * FROM order_summary_view，不用重复写四表 JOIN
• DBA 给财务组只授 SELECT 权限在 salary_report_view 上，该视图只 SELECT 姓名、部门、税后工资，不暴露身份证号、银行卡号等字段
• 基表 users 拆分为 users_basic 和 users_sensitive 后，只需修改视图定义，所有依赖该视图的报表代码无需改动

什么时候更适合用派生表而非视图

一次性、上下文强绑定的中间计算，用派生表更轻量、更可控。

• 查 “每个部门薪资前3的员工”，排序和 LIMIT 必须在子查询里完成，否则外层 LIMIT 会截断连接结果 —— 这种带 ORDER BY + LIMIT 的聚合必须用派生表：(SELECT dept_id, name, salary FROM employees ORDER BY salary DESC LIMIT 3) AS top3
• 嵌套层级深的分析，比如先算各渠道 ROI，再筛出 ROI > 1.5 的渠道并关联广告主信息，这种“一步一中间结果”的链式处理，用多层派生表比建多个视图更清晰
• 某些数据库（如早期 MySQL）对视图嵌套支持弱，或物化视图不可用时，派生表是唯一能稳定实现分步计算的方式

别名不是可选项，而是语法强制项

派生表没别名会报错，视图名本身就是别名，但容易被忽略的是：派生表中若含重复列名（如两个表都有 id），必须在子查询里显式重命名，否则外层无法引用。

• 错误写法：(SELECT id, name FROM users JOIN orders ON users.id = orders.user_id) —— id 二义性，MySQL 直接报 ERROR 1052
• 正确写法：(SELECT users.id AS user_id, users.name, orders.order_no FROM users JOIN orders ON users.id = orders.user_id) AS uo
• 视图虽不用每次写 AS，但创建时若未指定列别名，且底层 SELECT 含表达式（如 COUNT(*)），则默认列为 COUNT(*)，后续引用必须用反引号包裹，易出错

性能和调试差异常被低估

视图查询会被数据库优化器“展开”（view merging），而派生表默认强制物化（尤其 MySQL 8.0 以前），这直接影响执行计划和速度。

• 简单视图（如仅单表 SELECT）通常无性能损失；但含多层嵌套视图时，优化器可能放弃合并，导致全表扫描
• 派生表在 MySQL 中默认走 DERIVED 类型执行，如果子查询结果集大，会写入磁盘临时表，比等价视图慢一个数量级
• 调试时，EXPLAIN 看到 type=derived 就说明这里用了派生表；看到 select_type=VIEW 则是视图展开 —— 两者执行路径不同，不能简单互换

真正难的不是语法，而是判断“这个逻辑该固化还是该即用即弃”：业务口径长期稳定？涉及权限隔离？那就建视图；只是本次查询需要中间态、且后续不再复用？派生表更干净。二者混用也常见，比如用派生表预过滤，再 JOIN 到视图上——关键在分清边界，而不是强行统一。