CONCAT_WS比CONCAT更适合多列拼接，因其自动跳过NULL值、只需指定一次分隔符，且避免因单个NULL导致整体返回NULL；而CONCAT遇NULL即返NULL，且需手动重复添加分隔符。
CONCAT_WS 为什么比 CONCAT 更适合多列拼接？
因为 CONCAT_WS 自动跳过 NULL 值，且只需指定一次分隔符，不用为每对字段重复写分隔符。而 CONCAT 遇到任意参数为 NULL 就返回 NULL，还容易漏写分隔符，拼接 5 列就得写 4 次分隔符。
常见错误现象：CONCAT(col1, ',', col2, ',', col3) 中只要 col2 是 NULL，整条结果就变成 NULL；而 CONCAT_WS(',', col1, col2, col3) 会直接忽略 col2，输出 val1,val3。
-
CONCAT_WS第一个参数是分隔符（必须是非 NULL 字符串），后续所有参数都会被转为字符串并用该分隔符连接 - 空字符串
''是合法分隔符，可用于无间隔拼接 - MySQL 5.0.17+、PostgreSQL 9.1+、SQL Server 2017+、SQLite 3.11+ 均支持，但 Oracle 不支持（需用
||或LISTAGG）
如何安全处理 NULL 和空字符串混杂的字段？
即使用了 CONCAT_WS，如果业务上想把空字符串 '' 也视作“无效值”跳过，它默认不会跳——CONCAT_WS(',', 'a', '', 'c') 结果是 a,,c，中间多了一个逗号。
解决办法是用 NULLIF 预处理：把空字符串转成 NULL，再交给 CONCAT_WS。
SELECT CONCAT_WS(',', NULLIF(col1, ''), NULLIF(col2, ''), NULLIF(col3, '')) AS merged
FROM users;
- MySQL/PostgreSQL/SQL Server 都支持
NULLIF(expr1, expr2)：当expr1 = expr2时返回 NULL，否则返回expr1 - 如果字段可能含前后空格，建议先
TRIM(col)再NULLIF(TRIM(col), '') - 注意：在 WHERE 或 ORDER BY 中频繁使用这类表达式会影响索引使用，仅用于 SELECT 投影层
MySQL 中 CONCAT_WS 的实际性能和字符集陷阱
多数情况下 CONCAT_WS 性能与 CONCAT 接近，但有一个隐蔽问题：当拼接字段字符集不一致时（比如 utf8mb4 和 latin1 混用），MySQL 会隐式转换，可能触发全表扫描或报错 Illegal mix of collations。
- 执行前可用
SHOW FULL COLUMNS FROM table_name LIKE 'col%';查看各列字符集 - 稳妥写法是显式转码：
CONCAT_WS(',', CONVERT(col1 USING utf8mb4), CONVERT(col2 USING utf8mb4)) - 若某列是 JSON 类型，MySQL 8.0+ 会自动转为字符串；5.7 则报错，需先
CAST(col AS CHAR)
替代方案：什么时候不该用 CONCAT_WS？
当需要动态控制哪些列参与拼接（比如按条件跳过整列）、或拼接结果要参与索引查询、或目标数据库不支持时，CONCAT_WS 就不是最优解。
- PostgreSQL 用户可考虑
ARRAY_TO_STRING(ARRAY[col1, col2, col3], ',')，它天然跳过 NULL，且数组构造更易配合FILTER条件 - SQL Server 2017+ 推荐
STRING_AGG（需配合GROUP BY），单行拼接仍用CONCAT或+连接 - Oracle 必须绕开：
REPLACE(RTRIM(col1 || ',' || col2 || ',' || col3, ','), ',,', ',')—— 糟糕但有效
真正麻烦的不是语法本身，而是不同环境里 NULL 处理逻辑、字符集推导规则、以及空字符串是否等价于缺失值——这些细节往往只在上线后批量数据里暴露。
