SQL 视图仅保存一条 SELECT 语句定义，支持复杂逻辑（CTE、JOIN、窗口函数等），但禁用 DML 和过程语句；长度受系统限制（如 SQL Server 为 65536 字符）；不宜过度堆砌逻辑，因不可参数化、难调试、维护成本高；推荐用函数替代参数化需求，或分层视图 + 函数实现模块化。
SQL 视图能存多长的查询逻辑？
视图本身不“存储”逻辑代码，它只保存一条 SELECT 语句的定义。所谓“长逻辑”，本质是看这条 SELECT 能不能写得足够复杂——嵌套子查询、CTE、多表 JOIN、窗口函数都支持，但不能含 INSERT/UPDATE/DELETE、变量、循环或过程式语句。
- PostgreSQL/SQL Server/Oracle 允许在视图中用
WITH定义多个 CTE，逻辑分层清晰，实际就是模块化的一种体现 - MySQL 8.0+ 支持 CTE，但 5.7 及更早版本不支持，此时只能靠嵌套派生表（
(SELECT ……)）模拟，可读性陡降 - 视图定义长度受系统限制：SQL Server 是 65,536 字符，PostgreSQL 默认无硬限制（但过长会导致 pg_get_viewdef() 截断显示）
为什么不能把业务规则全塞进一个视图里？
不是语法不允许，而是维护成本会指数级上升。一个包含 5 层嵌套、12 张表关联、3 个自定义函数调用的视图，改一处逻辑可能牵连整个下游报表或应用层结果，且无法单测、无法复用片段。
- 视图不可参数化（标准 SQL 中），
WHERE条件必须写死或依赖外部传入的列值，没法像函数那样接收$1或@param - 没有执行计划缓存粒度控制：大视图被多次引用时，优化器可能重复解析、生成不同计划，反而拖慢性能
- 调试困难：出错时错误信息只报“视图某行语法错”，不会指出是内部哪个子查询崩了
替代方案：哪些场景该用函数而不是视图？
当需要参数、复用、隔离执行逻辑时，标量函数或表值函数（TVF）比视图更合适。尤其是 PostgreSQL 的 RETURN TABLE 函数、SQL Server 的内联 TVF，行为接近视图但支持输入参数。
- PostgreSQL 示例：
CREATE FUNCTION sales_by_month(year INT) RETURNS TABLE(month INT, total NUMERIC) AS $$ SELECT EXTRACT(MONTH FROM order_date), SUM(amount) FROM orders WHERE EXTRACT(YEAR FROM order_date) = $1 GROUP BY 1 $$ LANGUAGE sql; - SQL Server 内联 TVF 不带函数体，只返回单个
SELECT，可被优化器展开，性能接近视图；多语句 TVF 则有开销，慎用 - 注意权限：函数执行时以定义者（
DEFINER）或调用者（INVOKER）身份运行，视图默认继承调用者权限，这点常被忽略导致查不到数据
“模块化存储”的务实做法
真想拆解长 SQL 逻辑，优先靠数据库对象协作，而不是堆砌单个视图：用基础视图封装原子维度（如 v_customer_basic），再用上层视图组合（如 v_customer_summary），中间穿插自定义函数处理计算逻辑（如 calculate_ltv()）。
- 避免跨库引用视图：某些数据库（如 MySQL）不支持视图引用其他库的表，除非显式加库名前缀，且权限需单独授予
- 物化视图（如 PostgreSQL 的
CREATE MATERIALIZED VIEW）能缓存结果，但刷新机制（REFRESH）是手动或定时的，不适用于实时性要求高的逻辑 - 最易被忽略的一点：视图定义变更后，所有依赖它的查询不会自动重编译，旧执行计划可能沿用失效的统计信息，导致性能突降
