视图中直接在select列表写表达式即可实现自动计算列，如select price * quantity as total_amount from orders；数据库每次查询时实时计算，无需额外存储或触发器。
视图里直接写表达式就能自动计算列
SQL 视图本身不存储数据，只是保存查询逻辑，所以“自动计算列”本质上就是在 SELECT 列表中写数学表达式，数据库每次查视图时实时计算。不需要触发器、存储过程或额外字段。
常见错误是试图在视图定义里用 ALTER VIEW ... ADD COLUMN（语法不存在），或者误以为要先建计算列再引用——视图里没有“添加列”这回事，只有“选什么列”。
-
SELECT price * quantity AS total_amount FROM orders：这是最典型用法，total_amount是纯计算列，查视图时才算 - 支持四则运算、函数嵌套，比如
ROUND(unit_price * (1 + tax_rate), 2) - 注意 NULL 参与运算结果仍是 NULL，必要时用
COALESCE(price, 0) * COALESCE(quantity, 0)
不同数据库对计算列的别名和类型推断差异
视图列名由 AS 指定，但数据类型可能因数据库而异。PostgreSQL 会尽量推断精确类型（如 INT * INT → BIGINT），MySQL 5.7+ 默认按操作数最大精度推，而 SQL Server 可能截断小数位。
- 显式转换更可靠：
CAST(price * quantity AS DECIMAL(10,2)) AS total - SQLite 不检查类型，全靠运行时隐式转换，容易在比较时出意外
- Oracle 对
NUMBER表达式默认保留足够精度，但除法可能引入浮点误差，建议用ROUND(..., 2)
WHERE 或 JOIN 中引用计算列需谨慎
不能直接在视图定义的 WHERE 子句里用计算列别名（如 WHERE total_amount > 100），因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT，别名在 WHERE 阶段还不可见。
- 正确做法：重复表达式，
WHERE price * quantity > 100 - 或用子查询/CTE 封装视图逻辑，再在外层过滤别名
- JOIN 条件同理，
ON v1.total = v2.base_total无效，必须写原始表达式或改用子查询
性能影响取决于底层查询而非计算本身
简单四则运算（加减乘除）几乎无开销，瓶颈永远在扫描基础表、索引是否命中、连接方式。但若表达式含标量函数（如 UPPER()、DATEADD()）或子查询，就可能阻止索引下推，甚至让整个视图无法被物化（如 PostgreSQL 的 MATERIALIZED VIEW 要求确定性函数）。
- 避免在计算列里调用非确定性函数：
NOW()、RAND()、USER() - 如果频繁按计算结果过滤，考虑在基础表上建计算列（如 SQL Server 的
PERSISTED列）并索引它，而不是依赖视图 - PostgreSQL 用户注意：
MATERIALIZED VIEW刷新时会重跑整个SELECT，表达式越复杂，刷新越慢
真正容易被忽略的是 NULL 传播和跨数据库类型兼容性——同一句 price * quantity 在 MySQL 和 PostgreSQL 中可能返回不同精度，上线前最好在目标环境实测结果类型。
