create view包裹select+计算列是最直接做法，视图本质是保存的select语句，含表达式即为计算列；不可用order by（除非特定数据库支持）；避免select*；join需明确且有索引；where优先放外层以保兼容性；视图非物化，每次查询重算；修改用create or replace view。
用 CREATE VIEW 包裹 SELECT + 计算列是最直接的做法
视图本质就是保存好的 SELECT 语句，把带计算的字段写进去，后续查视图就自动执行算式。不需要额外声明“这是计算列”，只要 SELECT 里有表达式（比如 price * quantity、COALESCE(discount, 0)），它就是计算列。
- 视图定义里不能用
ORDER BY（除非配合TOP或LIMIT，但多数数据库不支持，MySQL 8.0+ 和 PostgreSQL 允许加ORDER BY但实际执行时仍可能被忽略） - 别在视图里写
SELECT *，一旦基表加字段，视图输出结构会变，下游 SQL 可能意外出错 - 如果计算涉及多表 JOIN，确保 JOIN 条件明确且有索引支撑，否则每次查视图都可能触发全表扫描
CREATE VIEW order_summary AS SELECT order_id, product_name, price, quantity, price * quantity AS total_amount, CASE WHEN status = 'shipped' THEN 1 ELSE 0 END AS is_shipped_flag FROM orders o JOIN products p ON o.product_id = p.id;
WHERE 条件放视图里还是外面？看过滤字段是否参与计算
如果 WHERE 用的是原始字段（如 status = 'shipped'），放视图定义里能减少中间结果集大小；但如果 WHERE 依赖计算列（如 total_amount > 1000），就必须写在查询视图时的外层，因为大多数数据库不支持在视图定义中直接引用别名做过滤。
- PostgreSQL 支持在视图里用
WHERE total_amount > 1000（只要该别名在 SELECT 中已定义），但 MySQL 不行，SQL Server 也不行 - 更稳妥的做法：视图只做“投影+基础关联”，过滤逻辑交给上层查询，避免跨数据库迁移时出问题
性能陷阱：视图不是物化结果，每次查都会重算
视图不存储数据，只是语法糖。如果计算列涉及子查询、窗口函数或跨大表 JOIN，每次 SELECT * FROM order_summary 都会完整执行一遍底层逻辑。
- 想提速？要么给基表关键字段建索引（比如
orders(product_id, status)），要么在支持物化视图的数据库（如 PostgreSQL 9.3+ 配pg_cron，或 Oracle）里定期刷新 - 简单算式（
a + b、UPPER(name)）几乎无开销；但(SELECT SUM(...) FROM ...)这类标量子查询，每行都会执行一次，极易拖慢
修改视图逻辑要用 CREATE OR REPLACE VIEW，别删再建
直接 DROP VIEW 再 CREATE VIEW 会导致依赖它的存储过程、其他视图失效（报 “invalid object”）。多数数据库支持原子替换：
- PostgreSQL / MySQL 8.0+ / SQL Server：用
CREATE OR REPLACE VIEW - SQLite：不支持
OR REPLACE，得先DROP VIEW IF EXISTS，再CREATE VIEW，但要注意权限和依赖链 - 替换前建议备份旧定义：
SELECT pg_get_viewdef('order_summary')（PostgreSQL）或查INFORMATION_SCHEMA.VIEWS
视图里的计算列不会自动同步基表结构变更——比如你给 products 表加了 tax_rate 字段，想在视图里用 price * (1 + tax_rate)，必须手动 ALTER VIEW（或 DROP+CREATE），数据库不会提示你漏改。
