CONCAT_WS返回NULL的根本原因是分隔符参数为NULL；它会跳过NULL值但保留空字符串，字符集不一致会报错，WHERE/ORDER BY中使用会导致索引失效。
CONCAT_WS 为什么一用就返回 NULL
根本原因几乎总是分隔符参数为 NULL。哪怕其他字段全非空，只要第一个参数是 NULL，整条结果就是 NULL。比如：CONCAT_WS(COALESCE(delimiter_col, NULL), a, b) 中如果 delimiter_col 本身是 NULL，COALESCE 返回 NULL，函数就崩了。
常见错误场景：
- 直接传字段当分隔符：
CONCAT_WS(separator_field, a, b)，而该字段值为NULL - 用子查询或表达式生成分隔符：
CONCAT_WS((SELECT ','), a, b)→ MySQL 不允许 - 误以为
IFNULL(NULL, ',')能兜底，却忘了它在分隔符位置不生效（语法报错）
安全写法只有一条：分隔符必须是确定非 NULL 的值，推荐用 COALESCE(delimiter_col, ',') 或字面量 ' | '。
空字符串 '' 和 NULL 在 CONCAT_WS 里表现完全不同
CONCAT_WS 会跳过 NULL，但**不会跳过空字符串 ''**——这点极易被当成“一样处理”而踩坑。
比如：CONCAT_WS('-', 'a', '', 'c') 结果是 'a--c'，中间有两个连字符；而 CONCAT_WS('-', 'a', NULL, 'c') 是 'a-c'。
所以是否保留分隔符位置，得看你业务要不要“占位”：
- 想跳过空字段、不保留分隔符：直接传原字段，如
CONCAT_WS(' ', first_name, middle_name, last_name) - 想让空字段显示为
'—'或'N/A'：用COALESCE(middle_name, '—') - 想让空字段变
''但避免多出连续分隔符：先IFNULL(middle_name, '')，再用TRIM(BOTH '-' FROM ...)清理，或应用层后处理
字符集不一致时 CONCAT_WS 会静默失败或报错
如果拼接字段来自不同表、不同字符集（比如一张是 utf8mb4，另一张是 latin1），MySQL 会抛出 Illegal mix of collations 错误，而不是自动转换。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
这不是性能问题，是硬性阻断。排查路径很明确：
- 查字段字符集：
SHOW FULL COLUMNS FROM table_name LIKE 'col_name'; - 统一改用
utf8mb4（推荐）：ALTER TABLE t MODIFY col VARCHAR(100) CHARACTER SET utf8mb4; - 临时绕过（不推荐）：显式转码，如
CONCAT_WS(' ', CONVERT(a USING utf8mb4), CONVERT(b USING utf8mb4))
注意：视图或存储过程中混用不同字符集字段，这个错误可能只在执行时暴露，上线前务必验证。
WHERE 或 ORDER BY 里用 CONCAT_WS 就等于放弃索引
CONCAT_WS 是纯计算函数，出现在 WHERE、ORDER BY 或 JOIN ON 条件中，会导致相关字段无法使用索引，强制全表扫描。
典型反例：
-
WHERE CONCAT_WS(' ', first_name, last_name) LIKE '%John%'→ 无法利用first_name或last_name上的索引 -
ORDER BY CONCAT_WS(' ', last_name, first_name)→ 排序走文件排序，不走索引
真要按拼接结果查或排，唯一靠谱方案是建生成列 + 索引：
ALTER TABLE users
ADD full_name VARCHAR(255) STORED AS (CONCAT_WS(' ', first_name, last_name)),
ADD INDEX idx_full_name (full_name);
这个细节常被忽略：函数本身再“优雅”，也改变不了它不参与索引优化的事实。拼接逻辑一旦进条件，就得换思路。
