CONCAT_WS 更适合条件合并，因其自动跳过 NULL 值并返回空字符串（非 NULL），而 CONCAT 遇 NULL 即整结果为 NULL；需用 NULLIF 处理空字符串混用，且注意跨数据库兼容性与性能优化。
CONCAT_WS 为什么比 CONCAT 更适合条件合并
因为 CONCAT_WS 自动跳过 NULL 值，而 CONCAT 遇到 NULL 就让整条结果变 NULL。你写 CONCAT('a', NULL, 'c') 得到的是 NULL，但 CONCAT_WS(',', 'a', NULL, 'c') 能正常输出 a,c——这正是“基于条件合并”的底层保障。
常见错误现象：CONCAT 拼接用户姓名字段时，中间名 middle_name 为 NULL，结果整条姓名消失；用 CONCAT_WS 就不会。
- 分隔符是第一个参数，且只写一次，不随字段重复
- 所有后续参数都会被检查是否为
NULL，NULL被静默丢弃 - 如果所有参数都是
NULL，返回空字符串（不是NULL）
怎么处理空字符串 '' 和 NULL 的混用场景
空字符串 '' 不等于 NULL，CONCAT_WS 不会跳过 ''。比如 CONCAT_WS('-', 'a', '', 'c') 输出 a--c，中间多了一个分隔符。
使用场景：从表中拼地址，city 是 '' 而非 NULL，会导致 省-市- 这种残缺格式。
- 先用
NULLIF(column, '')把空字符串转成NULL，再喂给CONCAT_WS - 例如：
CONCAT_WS(', ', NULLIF(province, ''), NULLIF(city, ''), NULLIF(district, '')) - MySQL 8.0+ 可用
TRIM配合判断，但NULLIF更直接
CONCAT_WS 在不同数据库里的兼容性差异
CONCAT_WS 在 MySQL、PostgreSQL、SQLite 中都支持，但行为有细微差别：
- MySQL：分隔符允许为
NULL，此时整个结果为NULL - PostgreSQL：分隔符不能为
NULL，否则报错ERROR: separator must not be null - SQLite：行为类似 MySQL，但对空分隔符处理更宽松
- SQL Server 和 Oracle **不支持**
CONCAT_WS，得用STRING_AGG（SQL Server 2017+）或自定义函数替代
如果你写的 SQL 要跨库运行，别默认它存在；上线前务必查目标数据库版本的手册。
性能和可读性上容易被忽略的点
很多人以为 CONCAT_WS 是语法糖，其实它在执行层做了优化：内部只遍历一次参数列表，跳过 NULL 后直接拼接，比手写多个 IFNULL 嵌套快且简洁。
但注意：如果字段本身带大量空白（如前后空格），CONCAT_WS 不会自动清理，拼出来可能变成 " 北京 , 朝阳区 "。
- 需要清洗时，优先用
TRIM包裹字段，而不是依赖分隔符“遮丑” - 避免在
WHERE或JOIN条件里用CONCAT_WS做匹配——无法走索引，查得慢 - 字段数超过 20 个时，MySQL 对
CONCAT_WS参数个数无硬限制，但可读性骤降，建议拆成子查询或视图
真正难的不是写对函数，是想清楚哪些字段该参与合并、哪些该提前过滤、哪些该保留原样——逻辑边界比语法细节更容易出错。
