MySQL用CONCAT拼接时NULL致整结果为NULL，需IFNULL处理；PostgreSQL用||操作符且NULL“短路”；SQL Server用+易因NULL或类型报错，推荐CONCAT函数；视图拼接会导致索引失效且排序规则需显式指定。
MySQL里用CONCAT拼接字段最稳妥
MySQL 5.0.3+ 默认支持 CONCAT，它接受任意数量参数，自动跳过 NULL 值（注意：不是转成空字符串，而是整个结果变 NULL，这点容易踩坑）。比如：
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;
如果 first_name 是 NULL，整条结果就是 NULL，不是 ' NULL'。要避免这个，得显式用 IFNULL 或 COALESCE：
SELECT CONCAT(IFNULL(first_name, ''), ' ', IFNULL(last_name, '')) FROM users;
PostgreSQL必须用双竖线||，不能用CONCAT函数
PostgreSQL 不识别 CONCAT 函数（除非你自己建或用扩展），原生拼接靠 || 操作符。它对 NULL 更“宽容”——任一操作数为 NULL，结果是另一侧的值（类似字符串“短路”）：
SELECT 'hello' || NULL; -- 结果是 'hello'<br>SELECT NULL || 'world'; -- 结果是 'world'
但要注意类型：两边必须都是字符串类型，否则报错 operator does not exist: text || integer。遇到数字字段得先转：
SELECT name || ' (id=' || CAST(id AS TEXT) || ')' FROM products;
SQL Server里+号拼接要防NULL炸掉整列
SQL Server 默认用 + 拼接，但它对 NULL 零容忍：只要任一操作数是 NULL，结果必为 NULL，且不报错、不警告，容易漏查。更麻烦的是，如果字段是数字类型，+ 还可能被解释为加法而非拼接（比如 name + 123），直接报类型转换错误。所以务必统一转字符串：
SELECT ISNULL(first_name, '') + ' ' + ISNULL(last_name, '') AS full_name FROM users;
SQL Server 2012+ 提供了 CONCAT 函数，它自动把 NULL 转为空字符串，推荐优先用：
SELECT CONCAT(first_name, ' ', last_name) FROM users;
视图定义中拼接字段要注意索引失效和排序行为
在视图里做字符串拼接，本质是每次查询都实时计算，无法走底层字段索引。如果后续要按拼接结果 WHERE 或 ORDER BY，性能会明显下降。另外，不同数据库对拼接后字段的默认排序规则（collation）继承逻辑不同：MySQL 通常继承第一个参数的 collation；PostgreSQL 默认用数据库级 collation；SQL Server 可能触发隐式转换警告。如果视图用于报表或导出，建议显式指定 collation，例如：
SELECT CONCAT(first_name COLLATE utf8mb4_unicode_ci, ' ', last_name) AS full_name FROM users;
不然上线后突然出现中文乱序或大小写不敏感匹配，很难回溯。
