SQL视图中如何实现字符串拼接：使用CONCAT或管道符

在数据库视图里做字符串拼接，这事儿看似简单，实则暗藏玄机。不同数据库的语法和“脾气”大不相同，稍不留神，就可能掉进NULL值陷阱或者性能坑里。下面就来聊聊几个主流数据库的具体操作和那些必须留意的细节。

MySQL里用CONCAT拼接字段最稳妥

在MySQL的世界里，CONCAT函数是拼接字符串的首选工具，从5.0.3版本开始就默认支持。它用起来很灵活，能接受任意数量的参数。但这里有个经典的“坑”：它对待NULL值的方式是“一粒老鼠屎坏了一锅粥”——只要参数里有一个NULL，整个函数的返回结果就直接变成NULL，而不是把NULL当作空字符串忽略掉。

举个例子：

SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

如果某条记录的first_name字段是NULL，那么这条记录的full_name结果也是NULL，而不是你期望的' NULL'。为了避免这种尴尬，必须显式地处理NULL值，用IFNULL或者COALESCE函数给NULL上个“保险”：

SELECT CONCAT(IFNULL(first_name, ''), ' ', IFNULL(last_name, '')) FROM users;

PostgreSQL必须用双竖线||，不能用CONCAT函数

切换到PostgreSQL，情况就变了。除非你手动创建或者启用扩展，否则原生的PostgreSQL根本不认识CONCAT这个函数。它的“官方指定”拼接操作符是双竖线||。

有意思的是，||操作符对NULL的态度要“友好”得多，甚至有点“短路”逻辑的味道：如果操作数一边是NULL，结果就直接是另一边的值。

SELECT 'hello' || NULL; -- 结果是 'hello'
SELECT NULL || 'world'; -- 结果是 'world'

不过，别高兴得太早。它有个严格的要求：操作符两边的数据类型必须都是字符串。如果你试图把字符串和数字直接拼在一起，就会立刻收到一个类型错误提示。所以，遇到数字字段，记得先把它“打扮”成字符串的样子：

SELECT name || ' (id=' || CAST(id AS TEXT) || ')' FROM products;

SQL Server里+号拼接要防NULL炸掉整列

SQL Server默认使用加号+进行字符串拼接，但这招用起来得格外小心。首先，它对NULL是“零容忍”的，只要参与拼接的任何一个操作数是NULL，最终结果就一定是NULL，而且整个过程静悄悄的，不会给出任何错误或警告，排查起来很头疼。

更麻烦的是类型混淆。加号+在SQL Server里身兼数职，它可能被解释为算术加法。如果你写name + 123，而name是字符串，系统很可能会报类型转换错误。因此，最安全的做法是统一转换为字符串，并提前处理NULL：

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通常会采用第一个参数的排序规则；PostgreSQL默认使用数据库级别的设置；而SQL Server则可能在混合不同排序规则的字符串时发出警告。如果这个视图用于报表或数据导出，特别是涉及中文排序或大小写敏感比较时，强烈建议显式指定统一的排序规则：

SELECT CONCAT(first_name COLLATE utf8mb4_unicode_ci, ' ', last_name) AS full_name FROM users;

提前做好这个约定，能有效避免上线后突然出现令人困惑的乱序问题，到时候再回头排查可就费劲了。