标量子查询拼接字段返回NULL的根本原因是未匹配时默认返回NULL，且字符串拼接中任一NULL导致整体为NULL；需用COALESCE()等兜底，避免N+1查询性能问题。
标量子查询拼接字段时，为什么总返回 NULL？
标量子查询在 SELECT 列表中必须返回 0 或 1 行、1 列，否则报错；但更常见的是“逻辑上应有值却得 NULL”——根本原因是子查询没匹配到记录时默认返回 NULL，且不会因外层行存在而“自动补空字符串”。
比如想拼接用户姓名和其最新订单的物流单号：
SELECT u.name, (SELECT tracking_no FROM orders o WHERE o.user_id = u.id ORDER BY created_at DESC LIMIT 1) AS last_tracking FROM users u;
若某用户从未下单，(SELECT ...) 就是 NULL，最终 name || last_tracking 整体变 NULL（多数数据库中字符串拼接含 NULL 即得 NULL）。
- 用
COALESCE()或IFNULL()显式兜底：COALESCE((SELECT ...), '') - PostgreSQL 还可配合
||拼接前加CONCAT()（它自动忽略NULL） - MySQL 8.0+ 推荐用
CONCAT_WS('', ...)，比嵌套IFNULL更清爽
拼接多个子查询字段，性能真的扛得住吗？
每个标量子查询都会为外层每一行独立执行一次，本质是 N+1 查询。1000 行用户 × 3 个子查询 = 至少 3000 次独立执行，索引再好也扛不住全表扫描式反复查找。
典型低效写法：
SELECT u.name, (SELECT title FROM posts p WHERE p.author_id = u.id ORDER BY p.id DESC LIMIT 1) AS latest_post, (SELECT COUNT(*) FROM comments c WHERE c.post_id IN (SELECT id FROM posts p2 WHERE p2.author_id = u.id)) AS total_comments, (SELECT MAX(score) FROM reviews r WHERE r.user_id = u.id) AS best_review FROM users u;
- 第三个子查询里又嵌套了子查询，复杂度指数级上升
- 缺少
user_id索引或posts(author_id, id)联合索引，性能雪崩 - 更稳的方式：先用
LEFT JOIN+ 窗口函数聚合出所需字段，再关联；或用LATERAL（PostgreSQL）/APPLY（SQL Server）替代多层标量
MySQL 和 PostgreSQL 在标量子查询拼接上的关键差异
MySQL 默认允许标量子查询返回多行（仅警告），PostgreSQL 严格报错 more than one row returned by a subquery used as an expression。这意味着同一段拼接逻辑，在不同库可能表现不一。
- MySQL 中
(SELECT name FROM users WHERE status = 'active')若有多人，可能静默返回第一行——这是隐患，不是特性 - PostgreSQL 强制你加
LIMIT 1或改用ARRAY_AGG(...)[1]等显式取值方式 - 拼接符号也不同：MySQL 用
CONCAT(a, b)，PostgreSQL 常用a || b，但后者遇NULL更脆弱 - PostgreSQL 支持
STRING_AGG()配合子查询做多值拼接（如把用户所有标签逗号连起来），MySQL 8.0+ 才有等效的GROUP_CONCAT()
真正优雅的拼接，往往要放弃标量子查询
当拼接涉及“最新”“最多”“平均”等聚合语义，标量子查询看似简洁，实则难维护、难优化、难调试。它掩盖了数据关系的复杂性。
- 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)预计算“最新订单”，再LEFT JOIN，逻辑清晰且可复用 - 需要多字段拼接时，优先考虑生成物化中间结果（如临时表或 CTE），避免重复子查询
- 如果只是展示层需求（比如后台列表），不如把拼接逻辑交给应用代码——数据库只管精准查，别替前端干活
标量子查询不是不能用，而是容易让人误以为“写得少=设计好”。一旦字段数增加、条件变复杂、数据量过万，最先拖垮性能的，往往就是那几个看似无害的括号里的 SELECT。
