前几天在帮同事调一个 PostgreSQL 查询他用 DeepSeek 问了一句“两个字段怎么拼一起”结果 AI 一口气给了他七八种写法从最普通的||到concat_ws、format甚至string_agg。他拿着这些方案试了一圈发现有的结果对、有的结果直接变 NULL越试越懵。这事让我觉得挺值得写一篇的——PostgreSQL 里“拼接字段”确实不止一种办法但每种办法的语义、容错和性能都不一样选错了轻则报表出现空白重则查询条件匹配不上。今天我把这个主题彻底掰开聊一聊。1. 为什么 PostgreSQL 里有这么多种拼接方式1.1 从 SQL 标准到 PG 的历史包袱||是 SQL 标准里定义的字符串连接操作符PostgreSQL 从最早的内核版本就支持它。你写a || b会得到ab这是 PG 最原生的拼接方式。后来开发者发现光有一个||不够用因为不同数据库对 NULL 的处理不一样。Oracle 里NULL || a结果是a但 PostgreSQL 里NULL || a结果是 NULL。为了让从 Oracle、MySQL 迁移过来的用户不那么痛苦PG 在 9.1 版本引入了concat()和concat_ws()这两个函数它们对 NULL 的处理更“宽容”——自动跳过 NULL不会让整个结果变成 NULL。再后来又加了format()它不只是拼接还能做占位符替换、动态 SQL 安全转义。加上聚合场景里常用的string_agg()以及array_to_string()、to_jsonb()这些间接实现拼接字段的方法自然就多起来了。所以说这个“多”不是设计混乱而是 PG 在标准、兼容性、易用性和扩展性之间不断平衡的结果。理解这一点你就不会执着于“哪种是唯一正确”而是先想清楚自己的场景需要什么样的 NULL 语义。1.2 NULL 语义是所有差异的根源拼接两个字段最容易翻车的地方不是语法而是 NULL 行为。用一个生活例子来解释||的逻辑像“复读机串联”中间任何一环是空白整条线就没声了。concat()的逻辑像“抄写员整理”遇到空白就跳过把剩下的字抄完。下面这张表总结了常用方法的 NULL 行为建议你直接收藏方法NULL 处理多字段拼接常用度||任一 NULL 则结果为 NULL支持但代码较长极高concat()自动跳过 NULL支持任意数量参数高concat_ws()自动跳过 NULL且不会出现多余分隔符支持第一个参数是分隔符高format()按照%s按字面替换NULL 会显示为空字符串支持模板中string_agg()跳过 NULL 行聚合多行不是普通两列高为什么这个差异如此重要因为业务表里“两个字段”经常有一个是空的。比如用户表拆分成了last_name和first_name但部分用户只填了一个再比如地址表有province、city、detail总有人不填市。你用||拼完结果一整列全部是空而用concat_ws拼至少能留下填了的那部分。1.3 拼接字段这件事使用频率远超你的想象两个字段拼接听起来是小操作但实际到处都是姓名、地址、订单号前缀、日期范围、报表标题、文件路径、JSON 输出、动态 SQL 条件……很多看起来简单的需求背后都是拼接。我见过一个真实案例某张报表的筛选条件是name字段但底层表把姓和名拆成了两列。开发直接用WHERE name last_name || first_name去匹配结果 3000 万行的表走了全表扫描因为拼接函数包住了列之后原来的索引完全用不上。这就是“拼接方式”背后隐藏的索引问题不实际踩一次很难意识到。2. 核心拼接方法逐一拆解2.1||操作符最正统也最容易踩空先说最常见的||。它用来拼接两个文本类型也可以连续拼接多个SELECT Hello || || PostgreSQL; -- 结果Hello PostgreSQL SELECT last_name || first_name FROM users; -- 如果 last_name 为 NULL则整行结果是 NULL||有个非常坑爹的限制当你拼接一个字符串和一个数字时PG 不会像 MySQL 那样自动帮你转字符串。比如SELECT 订单号 || order_id FROM orders; -- 如果 order_id 是 integer这里直接报错必须显式转类型SELECT 订单号 || order_id::text FROM orders;这类问题在从 MySQL 转 PG 的时候特别常见。MySQL 里CONCAT天生会自动转PG 的||则严格得多它遵循类型系统规则不会帮你“猜”。什么时候选||我一般只在两个字段都确定非 NULL、且类型确定时用它。它的好处是语义简单直接配合表达式索引也非常稳定。2.2concat()函数宽容派选手concat()是可变参数函数可以传任意多个字符串并且自动忽略 NULLSELECT concat(Hello, NULL, PostgreSQL); -- 结果HelloPostgreSQLNULL 被跳过 SELECT concat(last_name, first_name) FROM users; -- 即使 last_name 为 NULL也能返回 first_name它还自动做隐式类型转换数字、日期都能直接拼SELECT concat(订单号, order_id) FROM orders; -- 结果订单号10086注意这里的隐式转换对浮点数偶尔会有意外。比如concat(0.1 0.2)在某些精度控制下可能得到0.30000000000000004而0.1::text也会因为 PG 的浮点输出规则变成0.1。你要是拼小数点很多的数据建议先round()再拼。这个函数的缺点是没有分隔符参数。你想拼“姓 空格 名”必须自己写空格而且如果某一个字段是 NULL你会发现拼出来的结果没有空格变成“王小明”和“小明”两种情况。更麻烦的是当你拼三个字段中间那个是空的你会得到张三,,北京这种连续逗号。2.3concat_ws()带分隔符拼接的最佳实践concat_ws里的ws是with separator的意思。第一个参数是分隔符后面是任意多个字段它会自动忽略 NULL而且不会给 NULL 留下多余的分隔符SELECT concat_ws( , last_name, first_name) FROM users; -- 结果王 小明 / 小明如果 last_name 为空 SELECT concat_ws( - , city, district, detail) FROM address; -- 结果北京市 - 朝阳区 - xx路1号 -- 如果 district 为空结果是北京市 - xx路1号不会出现“北京市 - - xx路1号”这是我觉得日常开发里最省心的一种。你只需要关心“用哪个字符当分隔符”剩下的 NULL 清理交给函数。但是concat_ws也不是万能的。如果两个字段都是 NULL它返回的是空字符串而不是 NULL。这个细节在部分业务逻辑里需要注意比如你希望结果为空时走另一套判断那就得额外判断。2.4format()模板化拼接的高级选项format()是拼接家族里的“格式化大师”它按模板输出SELECT format(%s %s, last_name, first_name) FROM users; -- 相当于 concat_ws( , last_name, first_name) SELECT format(尊敬的客户 %s%s, customer_name, account_id); -- 适合生成固定格式文案除了%s表示字符串占位符还有%L表示字面量会自动加引号转义、%I表示标识符如表名、字段名会自动处理安全性。后两个在动态 SQL 场景里非常好用SELECT format(SELECT %I FROM %I, col_name, table_name); -- 结果SELECT col_name FROM table_name%I会自动把危险的标识符用双引号包起来比你自己拼字符串再执行安全得多。我用format()的场景一般不是普通查询而是写存储过程、动态 SQL或者批量生成脚本。普通 SELECT 里用它有点大材小用。2.5string_agg()聚合拼接多行的神器严格来说string_agg不是“拼接两个字段”而是“把多行数据的某个字段拼成一个字段”。但它属于同一个讨论范畴而且使用频率很高SELECT department_id, string_agg(employee_name, , ) FROM employees GROUP BY department_id; -- 结果1, 张伟, 李娜, 王强它也可以拼多个字段比如把“姓名工号”拼成列表SELECT department_id, string_agg(concat_ws(, employee_name, employee_id), ; ) FROM employees GROUP BY department_id;注意string_agg里的拼接顺序可以通过ORDER BY子句调整SELECT department_id, string_agg(employee_name, , ORDER BY hired_date DESC) FROM employees GROUP BY department_id;这个ORDER BY是写在聚合函数内部的不是写在GROUP BY后面很多新手会弄错。如果你需要把一组标签、一组 ID、一组关键词拼起来做展示string_agg是最直接的方案。它的执行效率也比你在应用层先查多行再循环拼字符串高得多。2.6 其它野路子数组、JSON 和 COALESCE除了上面四种主流方案PG 还提供了几种“间接”拼接方式。数组方式先构造数组再用array_to_string转字符串SELECT array_to_string(ARRAY[last_name, first_name], );这个方式对 NULL 的处理类似concat_ws但需要你保证数组元素类型一致否则还要显式转。JSON 方式当你最终要输出 JSON 格式时可以直接用jsonb_build_object或to_jsonb不需要手动拼字符串SELECT jsonb_build_object(name, last_name || first_name, city, city); -- 结果{name: 王小明, city: 北京}COALESCE 补偿方式当你特别喜欢||又不想让它被 NULL 连累可以配COALESCE手动兜底SELECT COALESCE(last_name, ) || COALESCE(first_name, ) FROM users;这种写法有效但代码很长字段一多就变得很难读。我不推荐在字段超过两个的场景里这么干。3. 实操建一张用户表跑通全部拼接方案3.1 建表和构造数据我建议你也按这个流程在自己的环境里跑一遍把各种方式的结果亲眼看一下。建一张简单的用户表CREATE TABLE users ( id integer PRIMARY KEY, last_name text, first_name text, job_title text, city text ); INSERT INTO users VALUES (1, 王, 小明, 工程师, 北京), (2, 李, NULL, 产品经理, 上海), (3, NULL, 小红, NULL, 广州), (4, 张, 伟, 设计师, NULL);注意第 2、3、4 行都包含了 NULL这样能把各种拼接差异暴露出来。3.2 完整姓名四种写法效果对比分别执行下面四条 SQL然后对比结果SELECT id, last_name || first_name AS a_operator, concat(last_name, first_name) AS b_concat, concat_ws( , last_name, first_name) AS c_ws, format(%s%s, last_name, first_name) AS d_format FROM users ORDER BY id;你会看到ida_operatorb_concatc_wsd_format1王小明王小明王 小明王小明2NULL李李李3NULL小红小红小红4张伟张伟张 伟张伟||在两处都返回 NULL而另外三个方法至少会把非 NULL 的部分保留下来。如果你的报表需要展示姓名concat_ws( , ...)最适合因为它还顺手处理了“名”和“姓”之间的空格。3.3 生成展示标签姓名 职位 城市下一步把姓名、职位、城市拼成一个展示标签SELECT concat_ws( - , concat_ws( , last_name, first_name), job_title, city ) AS user_label FROM users ORDER BY id;结果王 小明 - 工程师 - 北京 李 - 产品经理 - 上海 小红 - 广州 张 伟 - 设计师注意第 3、4 行的表现缺失的字段被直接跳过中间的“ - ”分隔符不会残留成连续的横杠。这个逻辑要用||写会很痛苦至少得 4 个COALESCE嵌套可读性极差。如果这段标签经常要用我通常直接把它丢进一个视图里业务层查视图就行CREATE VIEW v_user_label AS SELECT id, concat_ws( - , concat_ws( , last_name, first_name), job_title, city ) AS user_label FROM users;3.4 把拼接结果写回原表有时需要把拼接结果物化到原表字段里比如新增了一个full_name列ALTER TABLE users ADD COLUMN full_name text; UPDATE users SET full_name concat_ws( , last_name, first_name);执行完再查一下SELECT id, full_name FROM users ORDER BY id;第 2、3 行的full_name分别是李和小红而不是 NULL。用||写这条 UPDATE 的话第 2、3 行会变成 NULL后续一旦有程序直接读full_name字段不读拆分字段数据就“消失”了。这里我的习惯是先把 SELECT 版本的 SQL 跑一遍确认 NULL 行为符合预期再改成 UPDATE。千万别直接拿 UPDATE 在生产库上试。3.5 表达式索引让拼接字段也能走索引如果你经常按完整姓名查询比如SELECT * FROM users WHERE (last_name || , || first_name) 王, 小明;那么即使你在last_name、first_name上分别建了索引这个查询也走不了索引因为查询条件是拼接后的结果和单列索引对不上。解决办法是建表达式索引CREATE INDEX idx_users_full_name ON users ((last_name || , || first_name));这里有一个强制要求索引表达式必须和查询表达式完全一致包括逗号、空格、括号位置。你写SELECT * FROM users WHERE (last_name || , || first_name) 王, 小明;就必须用(last_name || , || first_name)建索引。如果你写成concat_ws(, , last_name, first_name)索引表达式也得换成(concat_ws(, , last_name, first_name))。我用EXPLAIN实测过表达式索引建立后同样的查询会从“Seq Scan on users”变成“Bitmap Index Scan”大表上速度差距是数量级的。但这个方案有个代价每次 INSERT / UPDATE 都要额外计算并维护这个索引所以别把一堆拼接组合都建索引只建查询频率最高的那一两种。4. 常见问题与排查技巧实录4.1 空值导致的“消失的字段”这是我见过最多的问题。同事说“我拼了字段但查出来是空”打开 SQL 一看十有八九是||遇到了 NULL。排查思路很简单先确认字段是否真的有 NULL。SELECT id, last_name IS NULL AS ln_null, first_name IS NULL AS fn_null FROM users;如果确实有 NULL果断换concat_ws或者在||外面套COALESCE。另外注意一点concat_ws的返回值不是 NULL而是。如果你后续对这个结果做了IS NULL判断会走不进预期分支。可以用NULLIF(result, )再把空串转回 NULL。4.2 数字、日期拼接时的类型转换异常SELECT 订单号 || order_id FROM orders;如果order_id是整数这条会直接报错operator does not exist: text || integer解决办法有三个-- 方法一显式转型 SELECT 订单号 || order_id::text FROM orders; -- 方法二用 concat自动转型 SELECT concat(订单号, order_id) FROM orders; -- 方法三用 cast SELECT 订单号 || CAST(order_id AS varchar) FROM orders;日期字段更麻烦。concat虽然能自动把日期转成字符串但格式是2025-01-15这种 ISO 格式不一定符合业务要求。更稳妥的做法是用to_char先格式化再拼SELECT concat(创建于, to_char(created_at, YYYY年MM月DD日)) FROM orders;4.3 分隔符重复、连续分隔符用||拼接多个字段时只要中间某个字段为空就会出现多余的分隔符。比如SELECT city || - || district || - || detail FROM address;district为空时会得到北京市--xx路1号非常丑。排查方法把拼接结果中的连续分隔符找出来SELECT city || - || district || - || detail AS addr FROM address WHERE city || - || district || - || detail LIKE %-%-%;修复方式就是换concat_ws(-, city, district, detail)它不会产生--。这是个一劳永逸的替换。4.4 拼接函数包裹字段导致索引失效刚才讲了表达式索引能解决但如果你在 WHERE 里用了concat这种函数包裹列并且没建对应索引全表扫描是必然的。-- 如果只在 last_name 上建了索引下面这个查询走不了 SELECT * FROM users WHERE concat(last_name, first_name) 王小明;我的建议别在 WHERE 条件里做复杂拼接。实在要支持这种查询就把“拼接后的值”冗余成一个新列写入时一次性算好查询时直接匹配单列这样最省心。数据量不大的表随便拼数据量上千万的表老老实实加冗余列或建表达式索引。4.5 中文字符串前后空格造成的拼接误差姓名、地址这类字段经常有不注意的多余空格拼接后会出现“王 小明”和“王 小明”不一致的问题。建议在拼接前统一清理SELECT concat_ws( , NULLIF(btrim(last_name), ), NULLIF(btrim(first_name), ) ) FROM users;NULLIFbtrim的组合能把“全空格字段”也当 NULL 处理避免出现一个纯空格冒充名字的情况。这个细节在清洗历史数据时特别有用。4.6 用 DeepSeek 这类 AI 辅助写拼接 SQL 时该注意什么回到开头的话题。用 DeepSeek 问拼接语法本身没问题但它的回答很容易“带偏”原因有三点一是它默认你可能来自 MySQL 背景有时给出CONCAT、CONCAT_WS这在 PG 里虽然也能用但 NULL 语义和你预期可能不一样。二是它不一定会主动提醒你索引问题如果你问的是“怎么查询姓名”它可能直接写WHERE last_name || first_name ...而不会提醒你全表扫描风险。三是它偶尔给出 PostgreSQL 8.x 时代的旧语法比如||单行拼接这在老项目里没问题但新项目里我会倾向concat_ws。正确做法是把表结构、字段类型、NULL 情况、PG 版本一起丢给它然后明确要求“请使用 PostgreSQL 15 语法并考虑 NULL 处理”。AI 返回的 SQL你自己一定要想清楚每种方法对 NULL 的行为。我的经验是让它同时给出||和concat_ws两个版本再对比数据结果比自己硬记语法有效得多。4.7 常见问题速查表现象可能原因推荐解法拼接结果全部为 NULL使用了||且其中一字段为 NULL改用concat_ws或套COALESCE报错 textinteger 不存在出现a--b连续分隔符固定写法拼接的中间字段为空改用concat_wsWHERE 条件很慢拼接函数包裹索引列索引失效建表达式索引或冗余列拼接结果多了奇怪小数位浮点数直接隐式转字符串先round()再拼分隔符后有空格残留原字段存在前后空格btrim()清理后再拼查询使用拼接字符串报错这是 MySQL 习惯改用||或concat5. 我的最终选型建议文章最后分享一套我在实际项目里沉淀出来的习惯。不需要记所有函数细节但遇到“拼接”这个需求按下面的顺序选就行。拼接两个字段且其中任一个可能为 NULL —— 默认选concat_ws( , 字段1, 字段2)。理由是它能处理 NULL、能处理空格分隔还不会多出连续分隔符。两个字段保证非 NULL并且后续可能要建表达式索引 —— 选||。原因是表达式索引里写concat_ws一样可行但||更接近 PG 原生操作EXPLAIN 出来也清晰。拼接多行结果比如分类列表、标签组合 —— 选string_agg记得把聚合排序写在函数内部。生成固定格式文案、邮件标题、日志头 —— 选format尤其是%I转义标识符这个能力在动态 SQL 里是安全兜底。输出 JSON 给前端 —— 别手动拼字符串直接jsonb_build_object或jsonb_build_array。数字和日期永远不要指望隐式转换 —— 先CAST或to_char再进拼接函数。另外有个细节值得说如果一张表的数据量超过百万行尽量不要把拼接逻辑写进高频查询的 WHERE 条件里。宁可多存一列冗余字段写入时算好查询时走普通索引。这比什么都快。PostgreSQL 的拼接方案多从来不是坏事。关键在于你清楚每种方案背后的 NULL 语义和索引影响。下次再拿 DeepSeek 或者其它 AI 工具问 SQL 拼接记得让它把函数的 NULL 行为一起列出来这样可以避免不少看起来玄学、实际上是数据库语义差异的 Bug。