concat_ws函数以第一个参数为分隔符，自动跳过null但保留空字符串；分隔符不出现于首尾，仅插入有效值间；全参数为null时返回null，否则结果非null。
CONCAT_WS函数的基本用法和分隔符行为
CONCAT_WS 是 MySQL 中专为带分隔符拼接设计的函数，第一个参数是分隔符，后续参数是待拼接的字段或表达式。它和 CONCAT 最大区别在于：**自动跳过 NULL 值，但不会跳过空字符串（''）**。
常见错误是误以为它会过滤掉空值，结果拼出类似 "a||c"（中间两个竖线），其实是第二个参数为 NULL 被跳过，而第三个参数是 '' 被保留了。
- 分隔符本身可以是任意字符串，包括空格、逗号、制表符甚至 emoji，但不能是
NULL；若传入NULL，整个函数返回NULL - 只要有一个非
NULL参数，结果就不会是NULL；全为NULL才返回NULL - 分隔符不会出现在开头或结尾，只在有效值之间插入
处理 NULL 和空字符串的典型陷阱
当字段可能为 NULL 或 '' 时，CONCAT_WS 表现不一致：前者被忽略，后者参与拼接。这常导致意外的多余分隔符。
例如：CONCAT_WS('-', 'a', NULL, '', 'c') 返回 "a--c"（注意中间两个短横），因为 NULL 被跳过，但 '' 被当作一个“有内容”的空字符串处理，于是 'a' 和 '' 之间加了一个 -，'' 和 'c' 之间又加了一个。
- 若想统一过滤空值（含
''），需提前用NULLIF(col, '')转换 - 若字段来自用户输入或表单，建议在应用层或 SQL 中先做清洗，避免混入
'' - 测试时务必用
IS NULL和= ''分别验证字段状态，不能只查IS NULL
与 CONCAT 混用时的类型隐式转换问题
CONCAT_WS 对参数类型宽松，会尝试转成字符串，但转换规则和 CONCAT 完全一致——比如数字 123 变成 "123"，时间类型变成默认格式字符串（如 "2024-05-20"）。问题出在混合使用时：
写成 CONCAT_WS(',', col1, CONCAT(col2, col3)) 看似合理，但一旦 col2 或 col3 是 NULL，内层 CONCAT 返回 NULL，外层 CONCAT_WS 就会跳过整个项，而不是跳过其中一个。
- 优先用
CONCAT_WS直接包裹所有原始字段，避免嵌套CONCAT - 需要条件拼接（如“有电话才加‘Tel:’前缀”）时，改用
CASE WHEN配合CONCAT_WS，不要依赖嵌套函数的返回值逻辑 - 对日期、数字等非字符串字段，显式用
CAST(... AS CHAR)或DATE_FORMAT控制格式，防止隐式转换出意料之外的结果
性能和索引友好性提醒
CONCAT_WS 是标量函数，无法利用索引加速，且在 WHERE 或 ORDER BY 中使用会导致全表扫描。它适合用于结果格式化，不适合用于查询条件构造。
比如 WHERE CONCAT_WS(' ', first_name, last_name) = 'John Doe' 不仅慢，还无法走 first_name 或 last_name 的索引；应拆解为 WHERE first_name = 'John' AND last_name = 'Doe'。
- 拼接逻辑尽量放在应用层或
SELECT列中，而非WHERE/HAVING/GROUP BY - 如果必须按拼接结果筛选，考虑增加生成列（generated column）并为其建索引（MySQL 5.7+ 支持）
- 大数据量下，频繁调用
CONCAT_WS在SELECT中虽不影响索引，但会增加 CPU 开销，可评估是否真需要实时拼接
真正容易被忽略的是：分隔符不是“装饰”，它承载语义边界；一旦字段内容本身含分隔符（比如地址里有逗号），CONCAT_WS 就完全无法区分结构和数据——这时候该考虑 JSON 字段或应用层解析，而不是硬拼。
