Oracle视图中应优先选||，因其支持多参数拼接且无ORA-00909错误；CONCAT()仅限两参数，多字段需嵌套，可读性差且中文场景可能乱码。

视图里拼字符串，优先用 ||，除非明确只跑 MySQL 或 SQL Server 2012+；CONCAT() 看数据库版本和参数个数，别无脑套用。

Oracle 视图中该选 || 还是 CONCAT()

Oracle 里 CONCAT() 只接受两个参数，三个字段一拼就报 ORA-00909: 参数个数无效。而 || 没这个限制，写 col1 || ' - ' || col2 || ' (' || col3 || ')' 完全合法，也更接近自然语言逻辑。

常见错误现象：把 MySQL 的写法直接搬进 Oracle 视图，比如 CONCAT(col1, ' - ', col2)，执行直接失败。

• 用 || 时，任一操作数为 NULL，整个结果就是 NULL；需要防空就套 COALESCE(col1, '')
• CONCAT() 同样对 NULL 敏感，且嵌套写法难读：CONCAT(CONCAT(col1, ' - '), col2)
• 如果字段含中文或特殊字符，|| 不会额外引发乱码；但用 CONCAT() 有时需配合 TO_CHAR() 显式转类型

MySQL 视图中为什么推荐 CONCAT() 而非 +

MySQL 不支持用 + 拼字符串（它会尝试转成数字相加），所以 CONCAT() 是唯一安全选择。8.0+ 还可直接上 CONCAT_WS()，省得手动处理分隔符和 NULL。

使用场景：比如拼地址字段 CONCAT_WS(', ', province, city, district)，自动跳过值为 NULL 的字段，不会出现 广东, , 天河 这种冗余逗号。

• CONCAT('a', NULL, 'c') 返回 NULL，不是 'ac'；必须提前用 IFNULL(col, '') 或 COALESCE(col, '')
• CONCAT_WS() 第一个参数是分隔符，后面所有参数都参与拼接，且天然忽略 NULL
• 老版本 MySQL（如 5.6）不支持 CONCAT_WS()，只能靠多层 CONCAT() + IFNULL()

跨数据库视图兼容性怎么破

如果视图要导出到不同 DBMS（比如先在 PostgreSQL 写，再适配 Oracle 和 SQL Server），|| 是最宽泛的选项——PostgreSQL、Oracle、DB2、SQLite 都原生支持；但 SQL Server 和旧版 MySQL 不认它。

这时候得做取舍：CONCAT() 在 MySQL 5.0+、PostgreSQL 9.1+、SQL Server 2012+ 都可用，但 Oracle 的 CONCAT() 功能残缺，不能当通用解。

• 不确定目标库时，优先写 ||，并备注“需 SQL Server/MySQL 用户替换为 + 或 CONCAT()”
• 若必须一份 SQL 跑多库，建议用视图包装层 + 数据库特定的物化视图，而不是硬塞兼容写法
• 别依赖 CONCAT_NULL_YIELDS_NULL 这类 SQL Server 特有开关，其他库没这机制

拼接时 NULL 导致结果意外为空，怎么排查

这是最隐蔽也最常踩的坑：表面语法全对，但查出来字段全是空——大概率某个参与拼接的列值为 NULL，而你用的拼接方式又恰好把它传染给整条结果。

不同数据库行为差异极大：

• Oracle || 和 MySQL CONCAT()：任一 NULL → 全局 NULL
• PostgreSQL CONCAT()：自动跳过 NULL；但 || 仍返回 NULL
• SQL Server CONCAT()（2012+）：跳过 NULL；+ 则传染 NULL

实操建议：只要字段可能为空，统一前置处理，例如 COALESCE(name, '') || '（' || COALESCE(dept, '') || '）'。别指望拼接函数帮你兜底。