视图命名须带业务前缀和逻辑后缀，如vw_sales_monthly_summary；必须显式声明schema；注释需说明用途、数据源变更影响及已知边界；禁用LIMIT和非确定性函数。
视图命名必须带业务前缀和逻辑后缀
很多人把视图当成临时查询快照，起名 v_user 或 view1，结果半年后连自己都看不懂它到底在聚合什么。命名本质是接口契约——别人靠名字判断能不能用、要不要改。
推荐格式：vw_{业务域}_{核心逻辑}，比如 vw_sales_monthly_summary、vw_customer_active_status。避免用 tmp_、test_ 这类暗示“随时会删”的前缀，视图一旦上线就是生产依赖。
- 不带前缀的
user_stats容易和表、物化视图、其他 schema 的同名对象冲突 - 后缀不用
_v（如user_v），因为 PostgreSQL/MySQL 不区分大小写，USER_V和user_v可能被误认为同一对象 - 全小写 + 下划线，跨数据库兼容性最好；别用驼峰或中划线（
userStats、user-stats在某些方言里要加引号才能用）
CREATE OR REPLACE VIEW 必须显式声明 SCHEMA
直接写 CREATE OR REPLACE VIEW user_summary AS ... 看似省事，实际埋下大坑：执行用户默认 schema 是谁？不同环境（dev/staging/prod）的 search_path 是否一致？漏掉 schema 很可能让视图引用了错误 schema 下的同名表，查不出数据却没报错。
正确写法永远带 schema：CREATE OR REPLACE VIEW reporting.vw_user_summary AS ...。哪怕当前只用一个 schema，也得写死——这是可重现性的底线。
- PostgreSQL 中
search_path变动会导致CREATE VIEW隐式绑定到不同 schema 的基表 - SQL Server 要求
CREATE VIEW必须含 schema（如dbo.vw_xxx），不写直接报错 - MySQL 5.7+ 虽允许不写 schema，但迁移至 8.0 或跨实例同步时，缺失 schema 会触发权限校验失败
注释必须覆盖三件事：用途、数据源变更影响、已知边界
视图不是代码函数，没有入参说明文档，别人只能靠注释理解它的行为边界。光写 “汇总用户订单” 没用，得说清“按自然日统计，不含退款订单，status=2/3/4 才计入”。否则下游报表突然少 15% 数据，第一反应是“视图坏了”，其实是逻辑本就如此。
把注释当契约来写，放在 CREATE OR REPLACE VIEW 语句上方，用 SQL 标准注释：-- 开头。别塞进视图定义里（比如 SELECT /* 订单数 */ COUNT(*)...），这种注释不入库，也不被元数据工具识别。
- 用途：一句话说明“这个视图回答什么业务问题”，例如
-- 返回近90天内完成支付且未退货的客户地域分布 - 数据源变更影响：例如
-- 若 orders 表增加 status=5（已取消），需同步更新 WHERE 条件 - 已知边界：例如
-- 注意：customer 表中 deleted_at IS NOT NULL 的记录仍被包含（软删除未过滤）
禁止在视图里写 LIMIT / OFFSET 或非确定性函数
LIMIT 100 看起来是防查爆，实则让视图失去组合能力——别人想基于它再 JOIN 或聚合，结果被截断，还查不出错。同理，NOW()、RANDOM()、UUID() 这类函数会让视图结果不可复现，测试难、排查难、缓存失效快。
需要分页或动态时间范围？交给调用方。视图只做“定义数据形态”，不做“控制输出量”。
-
LIMIT导致SELECT * FROM vw_user_orders JOIN orders_detail ON ...结果集意外缩水 -
NOW()在物化视图刷新、ETL 任务重跑时产生不一致快照 - MySQL 中
SYSDATE()比NOW()更危险——前者是语句执行时刻，后者是事务开始时刻，混用会引发时间逻辑错乱
视图的可维护性不在语法多炫，而在每个决策是否留痕、是否可推演。最常被跳过的其实是「数据源变更影响」那行注释——等基表字段删了、类型变了、索引没了，才想起当初没写清楚依赖关系。
