concat_ws比concat更适合拼接带分隔符的字符串，因其自动跳过null参数而非返回null，但需注意分隔符为null时整体返回null、空字符串仍参与拼接、索引失效及与group_concat的职责区别。
CONCAT_WS 为什么比 CONCAT 更适合拼接带分隔符的字符串
因为 CONCAT_WS 自动跳过 NULL 参数，而 CONCAT 遇到任意一个参数为 NULL 就直接返回 NULL。这是最常踩的坑——你以为只是某个字段空，结果整条拼接结果全没了。
典型场景：拼用户姓名（可能缺中间名）、拼地址（省市区某级为空）、拼标签列表（某些记录没打标签）。
-
CONCAT_WS(', ', '张', NULL, '三')→'张, 三'（正常） -
CONCAT('张', NULL, '三')→NULL（意外中断） - 第一个参数必须是分隔符，且只能是一个字符串，不能是表达式或列名
- 分隔符本身为
NULL时，整个函数返回NULL，这点容易被忽略
当字段含空字符串 '' 而非 NULL 时，CONCAT_WS 会怎么处理
它照常拼接，不会跳过空字符串。也就是说，'' 和 ' ' 都会被当成有效值参与拼接，可能产生多余分隔符或空白。
比如拼接姓名字段：first_name 是 '李'，middle_name 是 ''，last_name 是 '四'，那么 CONCAT_WS(' ', '李', '', '四') 得到的是 '李 四'（中间两个空格）。
- 如果业务上「空字符串」等价于「缺失」，得先用
NULLIF(col, '')转成NULL再喂给CONCAT_WS - 别依赖
TRIM()包裹在CONCAT_WS外面——它只能去头尾空格，解决不了中间冗余分隔符 - 想彻底避免空字段干扰，推荐组合写法：
CONCAT_WS(' ', NULLIF(TRIM(first_name), ''), NULLIF(TRIM(middle_name), ''), NULLIF(TRIM(last_name), ''))
CONCAT_WS 在 ORDER BY 或 WHERE 中使用的性能影响
它本身不走索引，一旦出现在 WHERE 条件右侧或 ORDER BY 表达式里，基本等于放弃该字段的索引加速。
比如 WHERE CONCAT_WS('-', year, month) = '2024-06'，哪怕 year 和 month 都有索引，MySQL 也无法利用。
- 需要按拼接结果查询时，优先考虑生成列（Generated Column）+ 索引：
ALTER TABLE logs ADD COLUMN ym VARCHAR(7) GENERATED ALWAYS AS (CONCAT_WS('-', year, month)) STORED, ADD INDEX idx_ym (ym); - 临时拼接用于展示没问题，但别让它钻进查询条件或排序逻辑里
- 在视图中用
CONCAT_WS不影响基表查询性能，但物化视图（MySQL 不原生支持）或频繁调用的存储函数要小心
和 GROUP_CONCAT 混用时要注意什么
两者名字像、都拼字符串，但完全不是一回事：CONCAT_WS 是行内横向拼接，GROUP_CONCAT 是跨行纵向聚合。混用时最容易犯的错是误以为它们能嵌套替代。
例如想按用户拼出“订单ID1,订单ID2”，却写了 CONCAT_WS(',', GROUP_CONCAT(order_id))——这其实多套了一层逗号，纯属冗余；而想拼“张三|北京|男”这种单行结构，用 GROUP_CONCAT 反而报错或出错数据。
-
GROUP_CONCAT默认最大长度是 1024 字符，超长会被截断，需提前设SET SESSION group_concat_max_len = 1000000; -
CONCAT_WS没长度限制（受 max_allowed_packet 控制），但参数个数上限是 MySQL 版本相关的，5.7 是 4096 个，8.0 也是，实际别传几百个参数 - 真要混合使用（比如每组拼一个带分隔符的摘要），应先
GROUP_CONCAT聚合，再在外层用CONCAT_WS补前缀/后缀，而不是反过来
