视图不能封装复杂商业逻辑计算，只能封装清洗、关联、基础聚合和确定性转换；真正复杂的计算（如跨时段状态推演、多步依赖判定、带事务更新）必须交由存储过程、CTE或应用层处理，否则会受限于字段固化、无法参数化、优化器失能三大瓶颈。
视图不能封装“复杂商业逻辑计算”本身，只能封装清洗、关联、基础聚合和确定性转换——真正复杂的计算（比如跨时段状态推演、多步依赖判定、带事务的更新）必须交给存储过程、CTE 或应用层，否则会卡在字段固化、无法参数化、优化器失能这三道坎上。
为什么CREATE VIEW ... GROUP BY后加新字段就报错
视图定义时的 SELECT 列表被固化，数据库不会动态解析下游查询中新增的聚合或别名。比如你建了：
CREATE VIEW sales_by_region AS SELECT region, SUM(amount) AS total FROM orders GROUP BY region;
后续查 SELECT region, total, COUNT(*) FROM sales_by_region 就会报 ERROR 1054: Unknown column 'COUNT(*)'——因为 COUNT(*) 不在视图原始定义里。
- MySQL/PostgreSQL/SQL Server 全部如此，不是 bug，是设计使然
- 视图本质是保存的
SELECT文本，不是中间结果缓存 - ORM（如 Django、SQLAlchemy）读取视图时会
DESCRIBE，字段缺失直接导致模型映射失败
哪些计算可以安全放进视图，哪些必须拦在外面
能放进去的：确定性、无副作用、不依赖运行时参数的逻辑。
- ✅ 字段补全：用
CASE WHEN flags & 4 = 4 THEN 'VIP' ELSE 'NORMAL'封装权限语义 - ✅ 关联增强：把
orders JOIN users JOIN products写进视图，下游只管SELECT - ✅ 基础过滤：剔除测试订单（
WHERE order_id NOT LIKE 'TEST%'）、清洗空值（COALESCE(phone, '')） - ❌ 时间范围动态切片：不能写
WHERE created_at >= '2024-01-01'，得留给外层WHERE - ❌ 多口径聚合：不能同时支持
GROUP BY region和GROUP BY region, year，二者字段集不同 - ❌ 状态流转计算：比如“最近一次下单距今天数”，涉及窗口函数且需参数，应改用 CTE 或函数
替代方案选型：什么情况该用 CTE，什么情况该用 ITVF
当你要复用一段带逻辑的查询，又不想被视图字段锁死，优先按场景选：
- PostgreSQL / MySQL 8.0+：用 CTE，写在查询开头，可读性强，优化器通常能内联展开
WITH clean_orders AS (SELECT * FROM orders WHERE status = 'paid') SELECT region, SUM(amount) FROM clean_orders GROUP BY region - SQL Server：用内联表值函数（ITVF），支持参数且谓词可下推
CREATE FUNCTION dbo.fn_orders_after(@dt DATE) RETURNS TABLE AS RETURN (SELECT * FROM orders WHERE created_at >= @dt)
调用：SELECT u.name FROM users u JOIN dbo.fn_orders_after('2024-06-01') o ON u.id = o.user_id - 需要物化结果或定时刷新：别碰视图，直接建汇总表 + 定时任务（MySQL 没物化视图，硬上
INSERT INTO summary_daily SELECT ...）
最容易被忽略的一点：视图里写了 ORDER BY 看似整齐，但只要外层再套一层查询（比如报表工具自动加 LIMIT 或 WHERE），排序就彻底失效——它不是约束，只是幻觉。
