concat_ws自动跳过null值，仅以首个非null参数为分隔符拼接后续非null字段；分隔符为null时结果全为null，且不支持动态分隔符或前后缀添加。
CONCAT_WS 的基本用法和 NULL 处理机制
CONCAT_WS 是 MySQL 中最常被低估的字符串函数之一，它默认跳过 NULL 值，而不是让整行变空——这直接解决了 CONCAT 最让人头疼的问题。它的第一个参数必须是分隔符（separator），后面所有参数才是待拼接字段；只要某个字段为 NULL，它就自动忽略，不插空档、不分隔符、不中断拼接。
常见错误现象：写成 CONCAT_WS(NULL, a, b)，结果整列全是 NULL——因为分隔符本身不能为 NULL，哪怕只错一次，全军覆没。
-
CONCAT_WS(' ', first_name, middle_name, last_name)：如果middle_name是NULL，结果就是'Zhang Li'，不是'Zhang Li'或'Zhang NULL Li' - 分隔符支持多字符，比如
CONCAT_WS(' → ', dept, team, role)，比嵌套CONCAT清晰得多 - 空字符串
''是合法分隔符：CONCAT_WS('', a, b)等价于CONCAT(a, b)，但依然跳过NULL
什么时候不该用 CONCAT_WS？分隔符限制与表达式陷阱
CONCAT_WS 要求第一个参数必须是字符串常量或确定不为 NULL 的列/表达式，不接受运行时计算的分隔符。一旦你在分隔符位置写了函数调用，比如 CONCAT_WS(IFNULL(suffix, '-'), a, b)，MySQL 会直接报错。
使用场景受限的典型例子：
- 需要按规则动态选分隔符（如“有 middle_name 用空格，否则用短横”）→ 必须改用
CONCAT+CASE或应用层处理 - 想在拼接结果开头或结尾强制加固定前缀/后缀（如
'[ ' || full_name || ' ]'）→CONCAT_WS不支持，得切回CONCAT - 字段本身含分隔符字符（如地址中带
' / '），拼出来可能语义混乱 → 需提前用REPLACE过滤，CONCAT_WS不负责清洗
CONCAT_WS 在 WHERE 条件里能用吗？索引失效风险
不能。和 CONCAT 一样，CONCAT_WS 是标量函数，出现在 WHERE 子句中会导致相关字段上的索引完全失效。例如 WHERE CONCAT_WS(' ', title, content) LIKE '%关键词%'，数据库只能全表扫描。
真正要查拼接内容，优先考虑：
- 建生成列（
GENERATED COLUMN）+ 索引：比如full_text VARCHAR(500) AS (CONCAT_WS(' ', title, content)) STORED，再对full_text加索引 - 业务允许时，把拼接逻辑下推到应用层，SQL 只查原始字段，避免数据库承担字符串加工负担
- 若必须 SQL 内完成模糊匹配，且字段少、数据量小，可接受性能损失，才临时用
CONCAT_WS，但务必加注释说明
跨库兼容性：CONCAT_WS 不是标准 SQL 函数
MySQL 和 MariaDB 原生支持 CONCAT_WS，但 PostgreSQL、SQL Server、SQLite 都不认这个函数名。如果你写的 SQL 要跑在多个数据库上，得换方案：
- PostgreSQL：用
array_to_string(ARRAY[a, b, c], ' ')，但需手动过滤NULL（ARRAY_REMOVE(ARRAY[a,b,c], NULL)） - SQL Server：没有等价函数，只能靠
ISNULL(a, '') + ' ' + ISNULL(b, '')拼，且NULL + anything = NULL，兜底不能漏 - 通用底线写法：用标准连接符
||（PostgreSQL、Oracle、SQLite 支持），但 MySQL 默认关闭PADDED模式时需启用sql_mode=PIPES_AS_CONCAT才生效
真正麻烦的从来不是怎么拼，而是拼完之后要不要参与查询、要不要跨库、字段里有没有隐藏的 NULL 或特殊字符——这些细节一漏，线上就出空结果或慢查询。
