关于 SQL 字符串拼接，有几个容易踩坑的核心要点：CONCAT() 遇到 NULL 会直接返回 NULL，而不是空字符串；CONCAT_WS() 则自动跳过 NULL，并且第一个参数作为分隔符，使用起来更安全；分隔符不能是 NULL，但可以是空字符串；另外，它不支持动态分隔符，需要借助 IFNULL 或 COALESCE 来做兜底处理。这些细节平时不出问题还好，一旦遇到就会导致整批数据查不到，值得提前摸清规律。
CONCAT() 遇 NULL 就返回 NULL，不是空字符串
很多开发者容易忽略一个底层行为：MySQL 的 CONCAT() 只要有一个参数是 NULL，整个结果就是 NULL，而不是 ''。举个例子：CONCAT('a', NULL, 'c') 得到的是 NULL，不是 'ac'。这会导致 WHERE 条件失效，SELECT 字段显示为空，而不是你预期的“跳过空值”。尤其在拼接 title、location 等允许为空的业务字段时，整行直接“消失”——这种问题在数据排查时特别隐蔽，容易让人忽略。
优先用 CONCAT_WS() 跳过 NULL，别硬套 CONCAT()
相比之下，CONCAT_WS() 才是更安全的默认选择——它的第一个参数是分隔符，后续参数中所有 NULL 值会被自动忽略，不插入空档、不中断拼接：
CONCAT_WS(' ', title, content, author, location)：哪怕location是NULL，也会拼出'足球新闻 体育频道 张三'，不会因为空值而导致整段结果归零。- 分隔符本身不能为
NULL，否则整条结果变为NULL；但空字符串''是合法分隔符，会让字段直接连在一起（如CONCAT_WS('', a, b)→'ab'）。 - 不支持在分隔符位置写表达式，比如
CONCAT_WS(IFNULL(suffix, '-'), ...)会报错，这点需要特别留意。
必须用 IFNULL() 或 COALESCE() 的场景
但有些场景，CONCAT_WS() 也搞不定。比如当你要控制每个字段的兜底值（不只是空字符串），或者需要兼容老版本 MySQL（<5.7）时，还是得请出 IFNULL 或 COALESCE：
CONCAT(IFNULL(title, ''), '｜', IFNULL(author, '佚名'), '（', CAST(year AS CHAR), '）')—— 这样每个字段都能按需设定默认值，而不是一律跳过空值。COALESCE()支持多 fallback，比如COALESCE(middle_name, nickname, '用户')，语义更清晰，适合多层级兜底场景。- 数字字段直接拼接可能触发隐式二进制转换（尤其旧版 MySQL），建议统一用
CAST(col AS CHAR)显式处理，避免意外类型问题。
WHERE 里用 CONCAT() 会丢索引，别这么干
在 WHERE 子句里写 CONCAT(title, content) LIKE '%关键词%'，数据库无法利用 title 或 content 上的索引，必然导致全表扫描。真正要按拼接内容检索，更推荐的做法是：
- 建生成列并加索引：
ALTER TABLE articles ADD full_text TEXT GENERATED ALWAYS AS (CONCAT_WS(' ', title, content, author)) STORED，再对full_text加全文索引，查询效率直接拉满。 - 应用层拼接：查出原始字段，在 PHP/Python 里组合后匹配，把计算压力从数据库移走，既灵活又可控。
- 改用多字段 OR 匹配：
WHERE title LIKE ? OR content LIKE ? OR author LIKE ?，语义更准、还能走索引，适合简单场景。
字符集不统一、跨库写法差异、分隔符误写成 NULL——这些细节不出错时没人注意，一出就是整批数据查不到。拼接逻辑越靠近业务规则（比如“有 middle_name 才加括号”），越该放在应用层，而不是塞进 SQL 里嵌套一堆 IF() 和 CONCAT()。记住：让数据库做它擅长的事，把复杂的条件判断交给应用层，才是稳妥之道。
