视图名不应包含日期或时间粒度，如v_sales_2024q3；正确做法是将时间控制下沉至WHERE条件（如dt BETWEEN ? AND ?），配合dt字段索引或原生分区表优化，并采用ord_order_monthly_agg等含业务域、类型标识的规范命名。
视图名带日期或时间粒度，查着快，改着疼
像 v_sales_2024q3 或 v_user_daily_20241001 这类名字，上线时看着“精准”，实际是给维护埋雷：每次换季度就得新建、重命名、改BI看板SQL、同步权限、清理旧视图。更麻烦的是，物化视图或查询重写根本认不出它是“同一逻辑的不同快照”，优化器直接放弃下推谓词。
正确做法是把时间控制下沉到查询层：
- WHERE 条件里用
dt BETWEEN ? AND ?或YEAR(dt) = 2024 AND QUARTER(dt) = 3 - 需要加速？在
dt字段建索引，或用原生分区表（MySQL 8.0+ / PostgreSQL） - 真要保留历史快照语义？建带版本号的物理表，比如
ord_order_snapshot_v2，而不是靠视图名模拟
嵌套超过两层，EXPLAIN 看不懂，性能也救不了
MySQL 8.0 以前不支持对三层及以上嵌套视图下推 WHERE 条件；PostgreSQL 虽支持，但执行计划里 cost 值会严重失真，你看到的“快”可能是假象。一旦底层表加了新索引，上层视图可能完全无法受益。
实操建议：
- 严格限制嵌套深度 ≤ 2 层：视图 A → 视图 B → 基表，不能再有视图 C
- 把中间聚合逻辑拆出来，优先走物化表（
CREATE TABLE AS SELECT...），尤其是日活、月结这类稳定口径 - 必须嵌套时，在最外层视图注释里写明依赖链，比如
-- depends on: usr_user_active_filtered, ord_order_monthly_agg
前缀用 v_ 或 vi_，等于没说业务归属
v_user、v_order、vi_sales —— 这些名字在单库小项目里还能凑合，一旦跨域（订单/用户/营销）、跨环境（dev/staging/prod）、跨团队协作，没人知道它归谁管、能不能直连、有没有权限过滤逻辑。
真正能降低沟通成本的命名，得同时表达三件事：
- 业务域：用缩写前缀，如
ord_（订单）、usr_（用户）、rpt_（报表） - 类型标识：紧跟其后，如
_agg（汇总）、_filtered（权限过滤）、_stg（ETL中间态） - 全小写 + 下划线，避免大小写敏感引发的跨平台问题（PostgreSQL 严格区分，MySQL 默认不区分）
例子：ord_order_monthly_agg 比 v_order_month 多出的信息量，够省掉一次会议对齐。
硬编码库名或 schema 名，迁移就崩
写成 CREATE VIEW v_user AS SELECT * FROM prod_db.users，看着明确，实则锁死了部署路径。换库名、切 schema、做读写分离时，所有依赖它的视图、函数、BI SQL 全得批量替换——漏一个，就是线上报错。
安全做法只有一条：
- 视图定义中永远不出现库名或 schema 名，只用裸表名；靠连接时的
USE db_name或连接串里的database=xxx控制上下文 - 如果真需跨 schema 关联，用同义词（MySQL 不支持，PostgreSQL 可用
CREATE SYNONYM）或代理视图（CREATE VIEW usr_user AS SELECT * FROM auth.users），但必须在文档里显式标注跨域依赖
复杂点不在语法，而在所有人默认“这个视图只属于当前 schema”——一旦打破，就必须显式声明，不能靠名字猜。
