CONCAT_WS能跳过NULL但出现双分隔符，是因为它只跳过NULL值，不跳过空字符串''；分隔符为NULL时整函数返回NULL；非字符串类型需显式转换；WHERE中使用会导致索引失效。
CONCAT_WS为什么能跳过NULL但结果里还有双分隔符？
因为CONCAT_WS只跳过NULL，不跳过空字符串''。比如CONCAT_WS(', ', 'a', '', 'c')结果是a,,c，中间两个逗号就是''被当普通字符串保留导致的。
常见错误场景：
- 地址字段清洗不彻底，
province存的是''而非NULL，拼出来变成"杭州,,中国" - 前端传参没做空值校验，后端写入
''，后续用CONCAT_WS拼接时出现冗余分隔符
解决办法不是靠函数本身，而是提前清理：NULLIF(col, '')把空字符串转成NULL，再交给CONCAT_WS处理；或者用TRIM(col) = ''判断后统一替换。
分隔符为NULL时整个函数返回NULL，怎么避免？
这是CONCAT_WS最隐蔽的崩点：只要第一个参数（分隔符）是NULL，不管后面参数多干净，结果一定是NULL。
典型踩坑写法：
-
CONCAT_WS(@sep, name, email)—— 如果@sep未初始化或查不到值，就是NULL -
CONCAT_WS(COALESCE(suffix, '-'), a, b)——COALESCE返回NULL时整条失效（虽然COALESCE本意是兜底，但这里它可能返回NULL）
安全写法只有两种：
- 硬编码分隔符：
CONCAT_WS(', ', name, email) - 用
COALESCE兜底分隔符：CONCAT_WS(COALESCE(@sep, ', '), name, email)，确保第一个参数绝不为NULL
传数字或日期字段时报错“Argument must be of type string”，怎么办？
CONCAT_WS对非字符串类型比CONCAT严格得多。传INT、DATE会直接报错，而CONCAT会隐式转字符串。
例如：CONCAT_WS(', ', id, name)在MySQL里会失败，必须显式转换：
- 用
CAST(id AS CHAR)—— 标准SQL写法，兼容性好 - 用
CONVERT(id, CHAR)—— MySQL特有，效果一样 - 避免用
id + ''这类隐式转换，不同版本行为不一致
注意：CONCAT_WS(', ', CAST(created_at AS CHAR), status)中，created_at是DATETIME类型，不转就会报错。
WHERE里用CONCAT_WS做模糊匹配，为什么查不出数据？
不是函数问题，是索引失效。哪怕你写WHERE CONCAT_WS(' ', first_name, last_name) LIKE '%john%'，数据库也无法命中first_name或last_name上的索引，只能全表扫描。
真实业务中更常见的陷阱：
- 以为加了
CONCAT_WS就能“安全拼接+搜索”，结果QPS暴跌 - 用
CONCAT_WS生成虚拟字段做排序，发现ORDER BY变慢且无法利用索引
替代方案优先级：
- 查前就用应用层拼接（如PHP/Python里
' '.join([first, last])），把计算压力从DB移走 - 真要DB侧处理，建生成列（generated column）并加索引，而不是每次查都算
- 模糊搜索场景，考虑全文索引或ES，别硬扛在
CONCAT_WS上
真正容易被忽略的，是分隔符和空字符串的边界行为——它们不会报错，但会让结果悄悄变脏，查起来像数据问题，其实是拼接逻辑没想清楚。
