视图中字符串拼接导致索引失效、重复计算和跨库兼容问题，须将清洗逻辑移至ETL或触发器，或使用计算列+索引；避免在视图中固化拼接表达式，以防全表扫描与执行路径失控。
视图里做字符串拼接不会预计算，每次查询都实时执行，且极易导致索引失效、隐式转换和跨库兼容问题——吞吐量下降不是偶然，是必然。
字符串函数在WHERE中直接作用于字段会彻底禁用索引
比如视图定义里写 SUBSTRING(name, 1, 10) 或 UPPER(email)，然后外部再加 WHERE UPPER(email) = 'ADMIN@EXAMPLE.COM'，数据库无法走 email 上的索引，只能全表扫描。
- MySQL/PostgreSQL/SQL Server 全部适用：函数包装字段 = 放弃索引
- 修复方式：把清洗逻辑移到 ETL 或 INSERT 触发器里，让字段本身存规范值（如已
TRIM(UPPER(name))） - 真要动态拼接，优先用计算列（
ALTER TABLE ADD clean_name AS UPPER(TRIM(name)) PERSISTEDin SQL Server）并对其建索引
多层嵌套拼接触发重复计算和临时内存分配
视图若含类似 CONCAT(COALESCE(first_name, ''), ' ', COALESCE(last_name, '')) 这类表达式，又在外部被多次引用（比如 SELECT 两次该字段、或用于 JOIN ON），数据库不会自动缓存中间结果——每处都重算一遍，还可能为每个结果分配新字符串内存。
- MySQL 8.0.23+ 可用
MATERIALIZEDCTE 强制物化，但视图本身不支持 - PostgreSQL 可建表达式索引：
CREATE INDEX idx_users_fullname ON users ((UPPER(TRIM(first_name || ' ' || last_name)))) - 更稳做法：把拼接逻辑下沉到基础表的生成脚本或视图外的查询层，避免在视图里固化低效表达式
跨数据库拼接语法不一致，迫使视图变成“方言黑洞”
一个视图若想兼容 MySQL、PostgreSQL、SQL Server，在字符串拼接上几乎无解：CONCAT() 在 MySQL/PG 里接受 NULL 不报错，SQL Server 要求显式 CONCAT_WS 或 + 配 ISNULL；|| 在 PG 是标准拼接符，在 SQL Server 默认关闭（需 SET CONCAT_NULL_YIELDS_NULL OFF）。
- 后果：同一份视图 DDL 在不同环境行为不同，甚至直接报错
ERROR 1064 (42000) - 规避方法：不在视图里做拼接，改用应用层或存储过程封装；或用视图只暴露原子字段，拼接留给调用方
- 如果必须统一，优先选
COALESCE(a, '') || COALESCE(b, '')（PG）、CONCAT(IFNULL(a,''), IFNULL(b,''))（MySQL），但 SQL Server 仍得单独处理
真正卡吞吐量的，从来不是拼接动作本身，而是它带来的索引失效、重复计算和执行路径不可控——这些在 EXPLAIN 里往往只显示为 rows=ALL 和 Extra: Using temporary，但根子就在视图定义那行看似无害的 CONCAT 里。
