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
||和 MySQLCONCAT()：任一NULL→ 全局NULL - PostgreSQL
CONCAT()：自动跳过NULL；但||仍返回NULL - SQL Server
CONCAT()（2012+）：跳过NULL；+则传染NULL
实操建议：只要字段可能为空，统一前置处理，例如 COALESCE(name, '') || '（' || COALESCE(dept, '') || '）'。别指望拼接函数帮你兜底。
