CONCAT_WS比CONCAT更适合拼接姓名、地址等字段，因其自动跳过NULL值，不中断拼接；而CONCAT遇任一NULL即返回NULL，易导致整行数据“消失”。
CONCAT_WS 为什么比 CONCAT 更适合拼接姓名、地址这类字段
因为 CONCAT 遇到任意一个 NULL 就整行返回 NULL，而真实业务表里 middle_name、dept、suffix 这类字段经常为空——你不是想“隐藏”这个人，只是想跳过空值继续拼。而 CONCAT_WS 天然跳过 NULL，不插空档、不分隔符、不中断拼接，语义更贴近“把有值的部分连起来”。
-
CONCAT_WS(' ', first_name, middle_name, last_name)→'Zhang Li'（当middle_name是NULL） -
CONCAT(first_name, ' ', middle_name, ' ', last_name)→NULL（只要middle_name是NULL） - 分隔符是
''（空字符串）也合法：CONCAT_WS('', a, b)等价于CONCAT(a, b)，但依然跳过NULL
分隔符为 NULL 会导致整列变 NULL，这个坑很多人踩过
CONCAT_WS 的第一个参数必须是非 NULL 字符串。一旦写成 CONCAT_WS(NULL, a, b)，哪怕 a 和 b 都有值，结果也是 NULL。这不是 bug，是设计行为——分隔符缺失，函数无法决定怎么拼。
- 错误写法：
CONCAT_WS(IFNULL(suffix, '-'), first_name, last_name)→ MySQL 直接报错，因为分隔符位置不接受表达式 - 正确做法：确保分隔符是常量或确定不为
NULL的列，比如CONCAT_WS('-', first_name, last_name)或CONCAT_WS(COALESCE(static_separator, ' '), ...)（但后者仍需保证static_separator列本身不为NULL） - 如果真要动态选分隔符（如“有 middle_name 就用空格，否则用短横”），得切回
CONCAT+CASE，CONCAT_WS不支持
CONCAT_WS 在 WHERE 条件里会彻底失效索引
和 CONCAT 一样，CONCAT_WS 是标量函数，出现在 WHERE 子句中会让优化器放弃使用任何原始字段上的索引。例如 WHERE CONCAT_WS(' ', title, content) LIKE '%关键词%'，数据库只能全表扫描。
- 真正要模糊匹配拼接结果，优先建生成列：
full_text VARCHAR(500) AS (CONCAT_WS(' ', title, content)) STORED，再对full_text加索引 - 数据量小、查询频次低且能接受性能损失时，才临时用
CONCAT_WS做条件，但务必加注释说明风险 - 业务允许的话，把拼接逻辑下推到应用层，SQL 只查原始字段，避免数据库承担字符串加工负担
跨库兼容性差，别在多数据库项目里硬写 CONCAT_WS
CONCAT_WS 是 MySQL / MariaDB 原生函数，在 PostgreSQL、SQL Server、SQLite 中不被识别。PostgreSQL 虽有同名函数，但行为不完全一致；SQL Server 根本没有它。
- 写跨库 SQL 时，要么统一用标准
||拼接符（确认各库是否启用sql_mode=PIPES_AS_CONCAT或等效配置），要么用COALESCE+CONCAT组合兜底 - 如果必须用
CONCAT_WS，建议在 DAO 层或视图层做适配，而不是让核心 SQL 依赖它 - 尤其注意：MySQL 8.0+ 支持窗口函数和 CTE，但
CONCAT_WS仍不能用在ORDER BY表达式里加速排序——它不改变字段可索引性
真正麻烦的从来不是语法，而是你没意识到那个 NULL 分隔符会让整列消失，或者没提前想到这句 SQL 下周就要跑在 PostgreSQL 上。
