视图是持久化虚拟表，派生表是单次查询临时生成的子查询结果；视图需预先创建、支持权限控制与复用，派生表无需定义、仅限当前查询使用且必须带别名。
视图和派生表都用于封装查询逻辑，但存在本质差异：视图是持久化对象，派生表是单次查询内临时存在的子查询结果。选哪个，取决于你是否需要复用、权限控制或跨查询一致性。
什么时候必须用视图而不是派生表
当你需要多次调用同一复杂逻辑，或要配合权限管理时，只能用视图。
- 多个应用模块反复查询 “用户订单汇总（含商品名、下单时间、实付金额）”，建
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 到视图上——关键在分清边界，而不是强行统一。
