MySQL中拼接字符串唯一可靠方式是CONCAT()，它自动跳过NULL值；PostgreSQL必须用||运算符并配合COALESCE处理NULL；SQL Server用+号但需ISNULL/CAST防错；跨库慎用CONCAT函数。
MySQL 里用 CONCAT 拼接常量和字段最稳
直接上结论：别用 + 或隐式转换，MySQL 默认不支持字符串加法运算符拼接，CONCAT() 是唯一可靠方式。它会自动跳过 NULL 值，避免整行变 NULL —— 这是新手掉坑最多的地方。
常见错误现象：SELECT name + ' (admin)' FROM users; 返回全是 0 或空值，因为 MySQL 把字符串当数字强转了。
-
CONCAT()所有参数都转成字符串再拼，遇到NULL直接忽略（比如CONCAT('a', NULL, 'b')→'ab'） - 如果真要保留
NULL占位，改用CONCAT_WS()，但分隔符会强制加在中间，不适合纯拼接 - 性能无压力，底层就是字节拷贝，比用
CAST++组合快且安全
示例：SELECT CONCAT(first_name, ' ', last_name, ' [ID:', id, ']') AS label FROM users;
PostgreSQL 必须用 || 运算符，不能用 CONCAT
PostgreSQL 不认 CONCAT() 函数（9.6 之前压根没这函数，10+ 虽然加了但行为和 MySQL 不同），硬套会报错 function concat(unknown, unknown) does not exist。
正确姿势只有两个：用双竖线 ||，或显式转类型后用 ||。
-
||是标准 SQL 字符串连接运算符，在 PostgreSQL 里优先级低，记得加括号避免歧义，比如(a || b) || c - 任意一边是
NULL，整个结果就是NULL—— 和 MySQL 的CONCAT()行为相反，这点必须手动处理 - 常用补救：用
COALESCE(col, '')把NULL转空字符串再拼，例如first_name || ' ' || COALESCE(middle_name, '') || ' ' || last_name
错误写法：SELECT CONCAT(name, ' (active)') FROM accounts; → 直接报错
SQL Server 的 + 号看着像加法，其实是字符串拼接
SQL Server 里 + 就是字符串连接操作符，但它有个致命特性：只要任意操作数是 NULL，结果必为 NULL。而且如果混了数字类型，会尝试隐式转换，失败就报错 Conversion failed when converting the varchar value 'abc' to data type int.
- 永远对可能为
NULL的字段套ISNULL(col, '')或COALESCE(col, '') - 数值字段必须显式转字符串：
CAST(id AS VARCHAR(10))或CONVERT(VARCHAR(10), id)，否则id + 'th'会报错 - 兼容性注意：ANSI_NULLS ON 是默认且推荐的，关掉它不会改变
+对NULL的处理逻辑
安全写法：SELECT ISNULL(first_name, '') + ' ' + ISNULL(last_name, '') + ' #' + CAST(id AS VARCHAR(10)) FROM staff;
跨数据库可移植写法：用标准 SQL 的 CONCAT 函数（谨慎）
SQL:2008 标准定义了 CONCAT()，但各数据库实现差异极大：MySQL 接受任意多参数、跳过 NULL；PostgreSQL 10+ 要求至少两个参数、也跳过 NULL；SQL Server 2012+ 支持但只接受两个参数，且任一为 NULL 就返回 NULL —— 看似统一，实则更难写通用逻辑。
所以除非你明确锁定 PostgreSQL 10+ 或 SQL Server 2017+，否则别指望靠一个 CONCAT() 走天下。
- 真正想跨库，不如老实用
||（PostgreSQL / Oracle / Standard SQL）+ 兼容层封装，或者干脆在应用层拼 - Oracle 也支持
||，但早期版本对NULL处理和 PostgreSQL 一致，同样要NVL()防空 - SQLite 用
||，行为接近 PostgreSQL，但不报错，NULL || 'x'得NULL
最易被忽略的一点：不同数据库对空格、制表符、不可见字符的 trim 行为不同，拼出来看着一样，LENGTH() 却不一样 —— 调试时别只看 SELECT 结果，得查 HEX() 或 DUMP()。
