SQL视图不支持运行时动态列名，所谓“动态字段”实为固定列名的逻辑列（如CASE表达式），真需切换列名须由应用层处理；统一用amount+currency两字段交由前端格式化更合理。
SQL 视图里怎么加“动态字段”？别真去拼字符串
视图本身不支持运行时计算列名（比如根据某字段值决定显示 amount_usd 还是 amount_cny），所谓“动态字段”实际是逻辑列（computed column）——用表达式生成值，但列名固定。真想切换列名，得靠应用层或前端配合，不是 SQL 能解决的。
常见错误现象：ERROR: column "dynamic_col" does not exist，往往是因为写了类似 SELECT CASE WHEN currency='USD' THEN amount END AS dynamic_col，却误以为这个列名能随数据变化。
- 逻辑列本质是表达式结果，列名在
CREATE VIEW时就固化了 - 如果业务上真需要“不同币种展示不同列”，建议统一用
amount+currency两字段，让前端决定格式化方式 - 硬要在 SQL 层“模拟动态列”，只能用
CASE分别展开所有可能字段，例如：SELECT amount_usd, amount_cny, CASE WHEN currency='USD' THEN amount_usd ELSE amount_cny END AS amount_display
MySQL / PostgreSQL 中 CASE 逻辑列的写法差异
虽然标准 SQL 支持 CASE，但不同数据库对空值、类型推导、索引友好度处理不同，直接影响视图性能和稳定性。
使用场景：按状态码映射中文描述、按金额区间打标签、按日期范围归类季度。
- PostgreSQL 对
CASE返回类型更严格，所有分支必须兼容，否则报错ERROR: CASE types text and integer cannot be matched；显式转类型更安全，比如CAST(... AS TEXT) - MySQL 允许隐式转换，但可能导致意外截断（如
CASE WHEN id=1 THEN 'active' ELSE 0 END会把'active'转成0） - 逻辑列无法被原生索引加速，如果视图底层表很大，且该列常用于
WHERE，应考虑在基表加生成列（GENERATED COLUMN）并建索引
视图逻辑列导致查询变慢？先看执行计划再改
逻辑列本身不存数据，但每次查视图都会重新计算。如果表达式涉及子查询、函数调用或跨表关联，性能损耗明显。
常见错误现象：原本秒出的表查询，套一层视图后变 5 秒以上；EXPLAIN 显示多了 Subquery Scan 或大量 Function Scan。
- 避免在逻辑列中调用非确定性函数，如
NOW()、RANDOM()、UUID()—— 它们会让整个视图无法被物化或缓存 - 如果逻辑列只是简单
CASE或算术运算（如price * tax_rate），影响很小；但嵌套三层CASE+COALESCE+ 字符串拼接，就得警惕 - PostgreSQL 12+ 可用
MATERIALIZED VIEW缓存结果，但需手动刷新；MySQL 没原生物化视图，得用临时表或应用层缓存代替
为什么不能用视图实现“用户自定义字段”？
真正意义上的动态字段（比如管理员后台新增一个 custom_field_1，所有视图自动多一列），视图做不到。它依赖静态 DDL，而自定义字段本质是 schema 变更，必须重建视图或换存储模型。
使用场景：SaaS 多租户系统、CRM 扩展字段、ERP 自定义属性。
- 试图用
SELECT * FROM base_table加一堆CASE模拟新字段，只会让视图越来越难维护，且无法应对字段增删 - 更可行的路径是：用 EAV 模型（不推荐）、JSON 字段（如
extra_attrs JSONB），或分离元数据表 + 动态 SQL（应用层生成查询） - 如果坚持用视图，至少把逻辑列封装进函数（如
get_custom_value(record_id, 'field_name')），但要注意函数内联限制和执行开销
最常被忽略的一点：视图的“动态感”全是假象。它不感知数据变更，也不响应 schema 更新。一旦基表加了字段，旧视图不会自动包含；一旦业务规则变，视图代码就得同步改——这恰恰是它和真正动态能力的分水岭。
