视图中不能使用order by，排序必须在调用视图的select语句末尾添加；group by视图需确保查询字段均出现在select列表中；多层嵌套视图易致性能下降，建议改用cte或临时表；mysql视图默认按definer权限执行，应显式指定sql security invoker以适配调用者权限。
视图里不能用 ORDER BY？那排序到底在哪做
SQL 视图本身不保存排序逻辑，ORDER BY 在视图定义中多数数据库（如 postgresql、SQL Server）会直接报错；MySQL 虽允许写，但实际执行时仍可能被忽略——因为视图只是“虚拟表”，最终排序必须由外部查询控制。
实操建议：
- 视图定义里删掉
ORDER BY，哪怕看着顺眼也别留 - 真正需要固定顺序的地方，是调用视图的
SELECT语句末尾加ORDER BY - 如果业务强依赖某排序（比如分页首屏），考虑把排序字段显式暴露在视图列中，方便上层明确引用
用 GROUP BY 的视图为什么总报“无效列”
常见错误是视图里写了 SELECT a, count(*) FROM t GROUP BY a，但调用方又想查 b 字段：SELECT a, b FROM my_view —— 这必然失败，因为 b 没出现在 GROUP BY 或聚合函数里。
关键点在于：视图的输出列结构在定义时就固化了，它不继承原表所有字段，只包含你写的 SELECT 列。
- 检查视图定义里的
SELECT列表，确保调用方要查的字段都在里面 - 如果原表有
b且需保留，要么加进GROUP BY，要么用MAX(b)等聚合包裹（注意语义是否合理） - 别指望“视图像表一样自由选列”——它比表更严格，尤其涉及聚合时
视图性能突然变差，先看是不是嵌套太深
一个视图基于另一个视图，后者又依赖第三个……这种链式嵌套在 PostgreSQL 或 oracle 中容易触发计划器误判，导致全表扫描或重复计算。MySQL 更明显，8.0 前几乎不优化多层视图。
判断方法很简单：用 EXPLAIN 查看最终查询执行计划，重点看 rows 和 Extra 字段是否出现 using temporary 或远超预期的行数。
- 单层视图通常无性能负担，问题多出在 3 层及以上嵌套
- 把中间层视图逻辑拆出来，改写成 CTE 或临时表，往往立竿见影
- 避免在视图里写
SELECT *，尤其是跨大表关联时——列越多，优化器越难剪枝
权限控制没生效？视图的 DEFINER 和 INVOKER 很关键
MySQL 中视图默认按 DEFINER 权限执行，即创建者权限；而 PostgreSQL 和 SQL Server 默认按调用者权限（INVOKER）。如果你在 MySQL 里建了个视图查敏感表，但只给普通用户开了视图 SELECT 权，却没给其 DEFINER 对应账号授权，查询就会直接报 Error 1449 (HY000): The user specified as a definer does not exist 或权限拒绝。
- MySQL 下建视图时显式指定
SQL SECURITY INVOKER，让权限检查落在调用者身上 - PostgreSQL 不用额外设，但要注意
SECURITY DEFINER函数调用视图时会覆盖行为 - 别假设“只要视图能建，就能查”——权限模型因数据库而异，得对号入座
视图不是语法糖，它是权限边界、执行上下文和查询重写的交汇点。写错一层，后面所有依赖都可能静默失效。