视图不能用变量或参数，应剥离可变逻辑至外层查询；避免过度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 限制，生产环境记得调大，否则深一点的树就截断

模块化不是堆视图，是让每个视图边界清晰、变更可控、失效可定位。最麻烦的从来不是写不出来，而是改一行，整条报表链路全红。