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()版本的行为。
