MySQL中CONCAT遇NULL即返回NULL，需用IFNULL或COALESCE预处理；PostgreSQL/SQL Server的CONCAT则自动将NULL视为空字符串，但PostgreSQL要求显式类型转换。
CONCAT 函数在 MySQL 中能自动跳过 NULL，但 PostgreSQL 和 SQL Server 不行
MySQL 的 CONCAT 遇到 NULL 会直接返回 NULL，而 CONCAT_WS 虽然用分隔符拼接，但也同样“怕 NULL”——只要任一参数为 NULL，整个结果就是 NULL。PostgreSQL 和 SQL Server 的 CONCAT（SQL Server 2012+、PostgreSQL 9.1+）反而更友好：它们把 NULL 当作空字符串处理，不会中断拼接。
所以安全拼接的第一步不是写逻辑，而是看数据库类型：
- MySQL：必须显式用
IFNULL()或COALESCE()替换NULL - PostgreSQL / SQL Server：可直接用
CONCAT()，但要注意字段隐式类型转换可能失败（比如拼接INT和TEXT） - SQLite：没有原生
CONCAT，得用||运算符，且NULL || 'a'结果是NULL，必须先COALESCE(col, '')
MySQL 下用 COALESCE 包裹每个可能为 NULL 的字段最稳妥
别依赖 CONCAT_WS('', col1, col2) 以为能“绕过 NULL”——它照样崩。真正起作用的是提前兜底。例如要拼接姓名全称：first_name、middle_name、last_name，其中中间名可能为空：
SELECT CONCAT( COALESCE(first_name, ''), ' ', COALESCE(middle_name, ''), ' ', COALESCE(last_name, '') ) AS full_name FROM users;
注意点：
- 每个字段单独
COALESCE(col, '')，而不是只包一层COALESCE(CONCAT(...), '')——后者整条失败才兜底，没用 - 空格等分隔符也得手动加，
CONCAT_WS的“自动分隔”不解决 NULL 问题 - 如果想让多个连续空格变一个（比如 middle_name 为空导致 “John Doe”），得额外套
TRIM()+ 正则或嵌套REPLACE，但那是另一层需求了
SQL Server 和 PostgreSQL 的 CONCAT 看似省事，但隐式转换容易报错
CONCAT('Name: ', first_name, ', Age: ', age) 在 SQL Server 里能跑，但在 PostgreSQL 中，如果 age 是 INTEGER，就会报错：ERROR: concatenation requires all arguments to be of the same type。PostgreSQL 更严格，不自动转类型。
解决方案很直白：
- SQL Server：基本没问题，
CONCAT内部会调用CAST做隐式转换 - PostgreSQL：必须显式转，写成
CONCAT('Name: ', first_name, ', Age: ', age::TEXT)或CONCAT('Name: ', first_name, ', Age: ', CAST(age AS TEXT)) - 别图省事用
||拼接混合类型——PostgreSQL 同样拒绝，且错误信息更模糊
别忽略性能和索引失效风险
在 WHERE 子句里用 CONCAT 做条件（比如 WHERE CONCAT(first_name, ' ', last_name) = 'John Doe'）会让索引完全失效，尤其是大表上等于灾难。即使你给 first_name 和 last_name 建了联合索引，CONCAT 表达式也无法命中。
更现实的做法是：
- 查询时拆开条件：
WHERE first_name = 'John' AND last_name = 'Doe' - 真需要模糊匹配全名，考虑生成计算列（SQL Server 支持持久化，MySQL 5.7+ 支持虚拟列并可建索引）并对其建索引
- 应用层拼接比数据库层拼接更可控，尤其涉及格式化（如补零、大小写统一）时
拼接本身不重，但一旦卷进查询条件、排序或 GROUP BY，就不再是字符串操作那么简单了。
