CONCAT遇NULL必返NULL是MySQL严格遵循SQL标准的设计行为；应优先用CONCAT_WS自动跳过NULL字段，但需搭配IFNULL将NULL转为空字符串以避免多余分隔符，且不可在WHERE中使用以免索引失效。
CONCAT函数遇到NULL直接返回NULL，不是你想要的空字符串
MySQL的CONCAT函数只要任意一个参数为NULL，整个结果就变成NULL。这不是bug，是设计行为——但它在拼接姓名、地址这类可能含空值的字段时，常导致意外的全空结果。
比如：CONCAT(first_name, ' ', last_name)，如果first_name是NULL，哪怕last_name有值，结果也是NULL，不是' John'或'John '。
- 这是SQL标准中
NULL传播规则的体现，不是MySQL特有 - 别指望靠WHERE过滤掉NULL来绕过——业务上往往需要保留记录，只是想把NULL“视为空”
- 用
CONCAT_WS也不能解决，它只跳过分隔符前后的NULL，但首尾NULL仍会污染结果
用CONCAT_WS + IFNULL组合最稳妥
CONCAT_WS（W表示With Separator）本身不解决NULL问题，但它和IFNULL配合能写出简洁、可读性强的拼接逻辑。
典型写法：CONCAT_WS(' ', IFNULL(first_name, ''), IFNULL(middle_name, ''), IFNULL(last_name, ''))
-
IFNULL(col, '')把每个可能为NULL的字段转成空字符串，再交给CONCAT_WS处理 -
CONCAT_WS自动跳过空字符串（注意：只跳过''，不跳NULL），所以不会出现多余空格 - 比嵌套多层
CONCAT(IFNULL(...), IFNULL(...))更清晰，也比COALESCE在简单场景下更直白
CONCAT_WS对空字符串的处理容易被忽略
CONCAT_WS确实会跳过NULL参数，但它**不会跳过空字符串''**——这点和很多人直觉相反。
例如：CONCAT_WS('-', 'a', '', 'c')结果是'a--c'，中间有两个连字符。
- 所以
IFNULL(col, '')必须搭配字段语义判断：如果该字段允许逻辑上“不存在”，才用''；如果它本应有值但缺失，可能更适合用'N/A'或'—'占位 - 若想彻底避免多余分隔符，得用
TRIM兜底，比如：TRIM(BOTH '-' FROM CONCAT_WS('-', ...))，但要注意性能开销 - MySQL 8.0+ 可用
REGEXP_REPLACE清理连续分隔符，但兼容性和可读性下降
性能与索引影响：别在WHERE里用CONCAT做条件匹配
虽然CONCAT本身计算很快，但一旦出现在WHERE子句里（如WHERE CONCAT(first_name, last_name) = 'JohnDoe'），会导致相关字段无法使用索引。
- 即使你给
first_name和last_name都建了联合索引，CONCAT也会让优化器放弃走索引 - 真要按拼接后值查询，优先考虑生成列（Generated Column）+ 索引：
ALTER TABLE users ADD full_name VARCHAR(255) STORED AS (CONCAT(IFNULL(first_name,''), IFNULL(last_name,''))); CREATE INDEX idx_full_name ON users(full_name); - 临时拼接展示用没问题，但别让它进查询条件——这是线上慢查高频诱因之一
join或f-string），数据库就越轻量；但若必须在SQL层做，CONCAT_WS配IFNULL就是目前最平衡的选择——既避开NULL陷阱，又不用写冗长CASE WHEN。 
