concat遇null即返回null，不会跳过或转为空字符串；concat_ws可跳过null参数，更安全；where/order by中使用concat会导致索引失效；跨数据库拼接应优先用||操作符。

CONCAT遇到NULL就返回NULL，不是跳过

这是最常被误读的一点：CONCAT不会把NULL当空字符串处理，只要任一参数是NULL，整个结果就是NULL。比如CONCAT(first_name, ' ', last_name)，哪怕last_name有值，只要first_name为NULL，结果就是NULL，不是' John'或'John '。

常见错误现象包括：查询结果大量为空、导出名单突然断掉、报表里“全名”列整列空白——十有八九是某个字段含NULL没兜底。

• MySQL 5.0.22+ 和 MariaDB 行为一致，都严格遵循“遇NULL即NULL”
• Oracle 的 CONCAT() 只支持两个参数，且同样返回NULL；想拼三个字段得嵌套：CONCAT(CONCAT(a,b),c)
• SQL Server 2012+ 的 CONCAT() 是个例外：它会自动把NULL转成空字符串，但老版本只能用+，而+仍遵循“NULL + anything = NULL”

用CONCAT_WS替代CONCAT更安全

如果你只是想把几个字段连起来、中间加个空格或逗号，又不想手动写一堆IFNULL()，CONCAT_WS()是更直接的选择。它的第一个参数是分隔符，后面所有参数自动跳过NULL，只拼非空部分。

例如：CONCAT_WS(' ', first_name, middle_name, last_name)，当middle_name为NULL时，结果是'John Doe'，不是'John Doe'（注意两个空格），也不会因middle_name为NULL而崩掉。

• 分隔符本身如果是NULL，整个函数返回NULL；但空字符串''是合法的，会被保留
• 它不支持在分隔符前后补空格逻辑（比如“有middle_name才加前后空格”），这种条件拼接建议移出SQL层
• 性能上比嵌套IFNULL()略优，因为只需遍历一次参数列表

WHERE或ORDER BY里别用CONCAT

在过滤或排序时对字段做拼接，比如WHERE CONCAT(first_name, last_name) LIKE '%john%'，会导致该条件无法走索引，数据库大概率触发全表扫描——数据量一过万，响应就明显变慢。

真正需要按拼接结果查或排，优先考虑：

• 建生成列（MySQL 5.7+）：ALTER TABLE users ADD full_name VARCHAR(100) GENERATED ALWAYS AS (CONCAT(first_name, ' ', last_name)) STORED，再给full_name加索引
• 应用层拼接：查出first_name和last_name，在代码里组合、匹配、排序，把计算压力从数据库卸下来
• 改用OR逻辑：WHERE first_name LIKE '%john%' OR last_name LIKE '%john%'，语义更准、还能命中单列索引

跨数据库拼接别硬套CONCAT

写SQL时如果不确定目标库类型，或者要兼容多个环境，CONCAT()不是安全选项。各库对它的支持差异不小：

• PostgreSQL：9.1+ 才有CONCAT()，但行为和MySQL不完全一致；更通用的是||操作符，且NULL || 'x'返回'x'，天然容错
• SQL Server：老版本必须用+，需配合ISNULL(col, '')；新版本虽支持CONCAT()，但团队若混用版本，容易埋坑
• SQLite：支持CONCAT()，但其实是||的别名，底层没区别
• Oracle：没有多参CONCAT()，||是事实标准，且NULL || 'x' → 'x'

真要跨库，优先测试||是否可用；不行再 fallback 到COALESCE(col, '')组合，而不是赌某个CONCAT()版本的行为。