SQL视图不支持参数，应将稳定逻辑（如JOIN、GROUP BY）封装进视图，动态过滤条件（如时间范围、状态值）留于外部查询；避免SELECT *、列名冲突及深层嵌套，确保谓词可下推。
视图里不能用参数，但可以用 WHERE 做运行时过滤
SQL 标准视图本身不支持传参，所以别指望写 CREATE VIEW v_orders_by_month(@year INT) 这种语法——所有数据库都会报错。真正可行的做法是：把最稳定的连接逻辑、计算字段、去重规则封装进视图，把变动的筛选条件（比如时间范围、状态值）留在外部查询中。
例如，订单汇总逻辑固定，但每次要看不同月份数据，那就把 JOIN、GROUP BY、SUM() 放进视图，而把 WHERE order_date >= '2024-01-01' 留给调用方。
- 视图定义中避免出现
WHERE子句（除非是业务强约束，如status != 'deleted'） - 如果必须预过滤，用
WHERE 1=1占位不如直接不写——更易读也更灵活 - PostgreSQL 和 SQL Server 支持物化视图，但 MySQL 直到 8.0.23 仍不支持，别在跨库迁移时默认假设能用
列名冲突和 SELECT * 是视图复用的最大隐患
用 SELECT * 创建视图看似省事，实际等于埋雷：上游表加字段、改类型、删字段，视图可能悄无声息地返回错序结果或报错 Column 'xxx' in field list is ambiguous。尤其多表 JOIN 时，同名列（如两个表都有 id、created_at）必须显式别名。
正确做法是：视图中每一列都带明确别名，且避免使用 table1.id AS id 这种弱别名——换成 table1.id AS order_id 或 table2.id AS user_id。
- 建视图前先跑一遍
SELECT主体，用EXPLAIN看是否走索引，避免视图一调就慢 - MySQL 中视图默认是
UNDEFINED算法，复杂视图可能被合并执行（MERGE），也可能被物化（TEMPTABLE），行为不可控；需要确定性时，显式指定ALGORITHM = MERGE - SQL Server 的视图支持
SCHEMABINDING，能防止底层表被删改，但会锁死表结构变更，上线前得跟 DBA 对齐
嵌套视图容易触发性能雪崩，三层以上就得警惕
视图可以引用其他视图，但每嵌套一层，优化器就越难做谓词下推（predicate pushdown）。比如 v_user_active 基于 v_user_base，而 v_user_base 又基于原始表——当外部查询加 WHERE last_login > '2024-01-01'，很可能这个条件根本下不到最底层表，导致全表扫描。
简单验证方法：在 PostgreSQL 用 EXPLAIN (VERBOSE)，在 MySQL 用 EXPLAIN FORMAT=TREE，看最终执行计划里 WHERE 条件是否出现在最内层扫描节点上。
- 优先扁平化：把
v_a → v_b → base_table改成v_a直接查base_table，只保留必要中间层 - 如果必须嵌套，确保每一层视图都只做不可省略的抽象（如脱敏、权限裁剪），而不是为了“看起来模块化”而拆
- Oracle 的视图有
WITH CHECK OPTION，能限制 DML 操作范围，但对 SELECT 性能无影响，别误以为它能加速查询
权限和跨 schema 引用在生产环境常被忽略
开发本地建好视图，上线后报 ERROR 1142 (42000): SELECT command denied to user，大概率是没给视图依赖的底层表授权。视图权限不继承——即使用户对视图有 SELECT 权，也不代表能访问其背后所有表。
另外，跨 schema 查询（如 sales.orders 和 common.users）在视图定义里必须写全限定名，否则迁移或换用户执行时容易找不到对象。
- MySQL 中用
SHOW CREATE VIEW view_name检查定义里是否含完整 schema 名 - PostgreSQL 需要确保
search_path设置一致，否则CREATE VIEW v AS SELECT * FROM users可能指向public.users而不是预期的app.users - SQL Server 视图依赖的表如果被
RENAME，视图不会自动更新，需要用sp_refreshview手动刷新元数据
视图复用真正的难点不在语法，而在权衡：什么时候该把逻辑下沉到视图，什么时候该留给应用层拼装。过度封装会让问题定位变慢，完全不封装又导致重复 SQL 散落在各处。上线前务必用真实数据量测一遍视图的执行计划和响应时间，而不是只看语法能不能通过。
