视图仅在逻辑复用层面减少重复SQL，不提升执行性能；其核心价值是统一维护查询逻辑，但存在嵌套性能退化、权限隐忧、依赖僵化及参数缺失等问题，需依场景慎选函数或CTE替代。
视图真能减少重复 SQL 吗
能，但只在「逻辑复用」层面成立，不是自动优化器意义上的“加速”。你写 SELECT * FROM user_active_view，和直接写它背后定义的 SELECT u.id, u.name FROM users u WHERE u.status = 'active' AND u.last_login > NOW() - INTERVAL 7 DAY，数据库执行的其实是同一套计划（除非用了物化视图）。关键收益是：改一处定义，所有调用自动生效。
- 适合场景：多张报表共用同一段过滤+关联逻辑（比如“近30天活跃付费用户”）
- 不适合场景：每次查询条件都不同（如动态传入
@date_start），视图里硬编码日期会锁死灵活性 - 注意：MySQL 5.7 及以前不支持视图中引用变量，
SET @d := '2024-01-01'后在视图里用@d会报错Unknown column '@d' in 'field list'
CREATE VIEW 时最容易漏掉的权限问题
创建视图的人，必须对底层表有 SELECT 权限；但调用视图的人，不一定需要这些权限——只要被显式授了视图的 SELECT 权限就行。这看似安全，实则埋雷：
- 如果视图里用了
JOIN多张表，而你只给调用者授了视图权限，没检查底层表是否被意外删掉或重命名，下次执行直接报Table 'db.old_table_name' doesn't exist - PostgreSQL 中，视图依赖关系默认不自动更新：删掉原表再重建同名表，视图仍指向旧 OID，查出来字段错位或报
relation "xxx" does not exist - MySQL 8.0+ 支持
ALGORITHM = MERGE（默认），但若视图含聚合或子查询，会被强制转为TEMPTABLE，性能可能比手写 SQL 差一截
视图嵌套三层以后为什么查不动
不是语法不允许，而是优化器放弃推导。比如 v1 基于 t1，v2 基于 v1，v3 基于 v2，MySQL 会把 v3 展开成三层嵌套子查询，而不是合并成单层扫描。现象是：单独查 v1 很快，查 v3 却慢十倍，EXPLAIN 显示 type=ALL 扫全表。
- 解决办法：把最外层视图改写成带明确
WHERE的查询，避免无条件SELECT * - 规避策略：超过两层嵌套就该警觉，优先考虑用 CTE 替代（MySQL 8.0+/PostgreSQL/SQL Server 都支持），CTE 至少不会无限展开
- 特别注意：SQL Server 的视图嵌套深度上限是 32，但实际到 5 层以上，查询计划缓存命中率就明显下降
替代方案：什么时候该用函数而不是视图
当逻辑需要参数驱动（比如按月份统计、按用户 ID 过滤），视图天生不支持传参，硬塞进 WHERE 条件又破坏复用性。这时该上标量函数或表值函数。
- PostgreSQL 示例：
CREATE FUNCTION active_users_since(p_days int) RETURNS TABLE(id int, name text) AS $$ SELECT id, name FROM users WHERE last_login > NOW() - $1 * INTERVAL '1 day' $$ LANGUAGE sql;—— 调用时SELECT * FROM active_users_since(7) - MySQL 注意：存储函数不能返回结果集，只能用存储过程 + 临时表模拟，但并发下容易冲突；更稳妥是用预处理语句封装逻辑
- 风险点：函数内联失败会导致性能雪崩，尤其 PostgreSQL 中未标记
STABLE的函数，优化器不敢下推条件
真正卡住人的从来不是“能不能用视图”，而是“该不该让这个逻辑脱离业务代码、固化进数据库”。一旦视图成了唯一真相源，下游应用改个字段名就得同步改十几处视图定义——这种耦合，比写三遍 SQL 还难维护。
