视图不能用变量或参数，应剥离可变逻辑至外层查询；避免过度JOIN和SELECT *；嵌套不超过两层；添加注释并检查依赖；MySQL旧版本不支持递归CTE需绕行。
视图里不能用变量或参数，硬写值会卡死迭代
SQL 视图本质是预定义的 SELECT 语句，数据库在创建时就固化了逻辑，不支持运行时传参。很多业务场景（比如按部门/时间范围动态过滤）一上来就想在视图里写 @dept_id 或 ${date}，结果报错或查不出数据。
正确做法是把可变部分剥离出去，在应用层或上层查询中组合：
- 视图只封装「稳定结构」：比如
user_order_summary视图固定关联用户、订单、商品三张表，算好总金额、订单数、最近下单时间 - 需要筛选时，外层再套
SELECT * FROM user_order_summary WHERE dept_id = 102 AND order_month >= '2024-06' - 如果必须参数化，改用表值函数（如 PostgreSQL 的
CREATE FUNCTION ... RETURNS TABLE，或 SQL Server 的内联表值函数），但要注意函数无法被所有优化器下推，可能影响性能
JOIN 顺序和冗余字段让视图变慢，不是越全越好
为了“方便”，有人在视图里把七八张表全 LEFT JOIN 上，还把所有字段 SELECT * 出来。结果一查就超时，执行计划里出现大量 Nested Loop 和临时表扫描。
关键要分清「建模意图」和「使用场景」：
- 一个视图只解决一类问题：比如
active_customer_metrics只关联用户表 + 最近30天订单表 + 退款表，不拉营销活动表 - 显式列出字段，避免
*：字段越多，IO 和内存压力越大；尤其别带TEXT/JSON大字段，除非真需要 -
LEFT JOIN要有明确业务依据：比如“要显示无订单用户”，才用LEFT JOIN orders；如果只是想补个用户等级，而等级表必有匹配，就该用INNER JOIN避免空行膨胀
嵌套视图超过2层就难调试，DDL 变更容易连锁崩
常见链路：v_sales_base → v_sales_region（基于 base 加地区维度）→ v_sales_kpi（再聚合）。某天修改 v_sales_base 的字段名或类型，后面两个视图直接 invalid，且错误信息只报“列不存在”，根本看不出源头在哪。
控制依赖深度比追求复用更重要：
- 最多两层嵌套：基础宽表视图（
v_user_order_enriched） + 业务指标视图（v_user_ltv_by_cohort），中间不插“中间态”视图 - 所有视图加注释：用
COMMENT ON VIEW v_xxx IS '来源：users+orders+products；不含测试用户（WHERE is_test=false）' - 变更前先查依赖：
SELECT * FROM pg_depend WHERE refobjid = 'v_sales_base'::regclass;（PostgreSQL）或sys.dm_exec_describe_first_result_set(N'SELECT * FROM v_sales_base', NULL, 0)（SQL Server）
MySQL 8.0+ 才支持递归 CTE 视图，旧版本得绕开
想用视图表达组织架构树、BOM 物料清单这类层级关系？MySQL 5.7 及之前版本的视图不支持 WITH RECURSIVE，强行写进去会报 ERROR 1064 (42000)。
替代方案得看实际需求强度：
- 层级浅（≤3级）、变化少：用固定多层
LEFT JOIN模拟，比如org AS o1 LEFT JOIN org AS o2 ON o1.parent_id = o2.id LEFT JOIN org AS o3 ON o2.parent_id = o3.id - 需要实时递归：放弃视图，改用存储过程或应用层处理；或者升级到 MySQL 8.0+ 后，用
CREATE VIEW v_org_tree AS WITH RECURSIVE tree AS (...) - 注意权限：递归视图默认受
max_recursive_iterations限制，生产环境记得调大，否则深一点的树就截断
模块化不是堆视图，是让每个视图边界清晰、变更可控、失效可定位。最麻烦的从来不是写不出来，而是改一行，整条报表链路全红。
