SQL中||拼接遇NULL返回NULL，而CONCAT()函数多数跳过NULL；跨库应统一用COALESCE等函数转空字符串后再拼接，避免逻辑错误。
SQL 中 || 拼接遇到 NULL 会直接返回 NULL
多数支持标准 SQL 的数据库（如 PostgreSQL、Oracle）中，|| 是字符串连接操作符，但它对 NULL 非常敏感：只要任意一侧为 NULL，整个结果就是 NULL。这不是“空字符串”，而是真正的 NULL，后续参与计算或比较时容易引发意外。
常见错误现象：
执行 SELECT 'a' || NULL || 'b' 得到 NULL，而不是 'ab'；在 WHERE 或 ORDER BY 中隐式依赖该值时逻辑断裂。
- PostgreSQL 默认行为如此，无法关闭
- Oracle 同样遵循该规则（但可通过
NVL()显式兜底） - 注意：SQLite 是个例外——它把
NULL当作空字符串处理，所以'x' || NULL返回'x'，但这属于非标准行为，不可跨库迁移
CONCAT() 函数默认跳过 NULL 参数（MySQL 行为）
MySQL 的 CONCAT() 函数设计上更“宽容”：它会忽略所有 NULL 参数，只拼接非 NULL 的字符串。比如 CONCAT('a', NULL, 'b') 返回 'ab'，不会中断。
但要注意这个“宽容”仅限于 MySQL。PostgreSQL 也有 CONCAT()，但它的行为不同：
PostgreSQL 的 CONCAT() 确实也跳过 NULL，但前提是至少有一个参数非 NULL；如果全为 NULL，则返回空字符串（''），不是 NULL。
- MySQL
CONCAT()：任一参数为NULL→ 整体跳过该参数 - PostgreSQL
CONCAT()：同上，且CONCAT(NULL, NULL)→''（空字符串） - SQL Server 没有原生
CONCAT()（2012+ 才引入），其+运算符和||一样，遇NULL即得NULL
跨数据库安全拼接的推荐写法
想写出可移植、不因 NULL 崩溃的拼接逻辑，不能依赖 || 或裸用 CONCAT()。核心思路是：先统一把 NULL 转成空字符串，再拼接。
推荐组合：COALESCE(col, '') 或 IFNULL(col, '')（MySQL）或 NVL(col, '')（Oracle）。
- PostgreSQL / 标准 SQL：
COALESCE(first_name, '') || ' ' || COALESCE(last_name, '') - MySQL：
CONCAT(IFNULL(first_name, ''), ' ', IFNULL(last_name, '')) - 避免写
CONCAT(first_name, ' ', last_name)—— 只要任一字段为NULL，整条记录就“消失”在结果里
性能与可读性取舍：函数 vs 操作符
|| 是操作符，通常比函数调用轻量；CONCAT() 是函数，涉及解析、参数检查等开销。但在绝大多数业务查询中，这点差异可忽略。
真正影响性能的是 NULL 处理方式带来的执行计划变化：比如用 || 拼接后做 WHERE full_name = 'xxx'，而 full_name 因含 NULL 字段变成 NULL，导致索引失效或过滤失败。
- 别为了“看起来快”而用
||冒险——NULL 导致的逻辑错误远比微秒级性能损耗严重 - 在视图或计算列中定义拼接逻辑时，务必显式处理
NULL，否则
下游应用会反复踩坑
- PostgreSQL 用户尤其注意：
CONCAT()虽跳过NULL，但它内部仍需类型推导，若混用数字和字符串（如CONCAT(123, 'abc')），可能触发隐式转换警告
GROUP BY）或去重（DISTINCT）时，NULL 导致的空值聚合行为——它既不算入任何组，也不等于空字符串，这种静默差异最难调试。
