concat函数的null传播机制是硬性规则，不是bug：只要任意参数为null，结果必为null，这是sql标准定义的“未知值”传播行为，会导致update中数据被静默置空。
CONCAT函数的NULL传播机制是硬性规则，不是bug
MySQL中CONCAT()只要任意一个参数为NULL，整个结果就一定是NULL。这不是偶然失效，而是SQL标准定义的“NULL传播”行为——它把NULL当作“未知值”，而“未知 + 任何东西”仍是“未知”。所以你在UPDATE里写SET name = CONCAT(first_name, ' ', last_name)，哪怕last_name只是某几行是NULL，这几行的name就会被更新成NULL，而不是你预期的'John '或'John'。
UPDATE中用CONCAT导致数据丢失的典型场景
常见于以下几类操作，容易在不察觉时覆盖有效数据：
- 用
CONCAT拼接来源字段（如source_table.first_name和source_table.last_name）批量更新目标表，但源表存在NULL值 - 拼接常量与字段，例如
CONCAT('USR-', id, '-', created_at)，其中created_at为NULL（比如未初始化的时间字段） - 关联查询后拼接，
LEFT JOIN产生的右表字段为NULL，直接喂给CONCAT却不加兜底
这类操作不会报错，UPDATE语句能成功执行，但部分记录的字段被静默设为NULL，后续业务读取时可能触发空指针、展示异常或统计偏差。
三种可靠兜底方式及适用边界
不能只靠WHERE col IS NOT NULL过滤，因为业务上往往需要保留这些记录；也不能依赖应用层补救，因为UPDATE已发生。必须在SQL内完成防御：
-
IFNULL(col, '')：最常用，语义清晰，适合字段逻辑上“可选”（比如中间名、昵称）。注意IFNULL(NULL, '')返回''，不是NULL，可安全传入CONCAT -
COALESCE(col, '')：功能等价于IFNULL，但支持多参数（如COALESCE(col1, col2, '')），适合 fallback 链式兜底 -
CONCAT_WS(' ', IFNULL(first_name, ''), IFNULL(middle_name, ''), IFNULL(last_name, ''))：当需分隔符且要跳过空字段时首选。注意它跳过NULL，但不跳''——所以仍要先用IFNULL转空串，否则CONCAT_WS(' ', 'a', '', 'c')会得'a c'（中间有空格）而非'ac'
容易被忽略的隐性陷阱
真正踩坑的点往往不在主逻辑，而在细节：
-
CONCAT对数字类型字段也生效，但若该数字字段值为NULL（比如INT列未赋值），一样触发传播——别以为只有VARCHAR才要处理 - 在
WHERE子句里用CONCAT做条件（如WHERE CONCAT(name, surname) LIKE '%john%'）会导致索引失效，且同样受NULL污染，查不到含NULL字段的记录 -
CONCAT_WS看似“免疫NULL”，但它对首尾NULL的跳过是“参数级”的，如果第一个参数就是NULL，它仍会从第二个非NULL开始拼——这点和直觉不符，务必实测验证
实际写UPDATE前，先用SELECT加相同表达式预查一遍，确认没有意外NULL产出，比事后修复成本低得多。
