标量子查询必须严格返回单行单列，否则执行时直接报错（如“Subquery returns more than 1 row”）；常见原因包括漏关联外层字段、字典表无唯一约束、模糊匹配或多值条件；正确做法是补全等值关联、建唯一索引，或优先改用LEFT JOIN替代。
标量子查询必须返回单行单列，否则直接报错
SQL执行时，如果SELECT列表里的标量子查询返回多于一行（比如漏加WHERE code = t.type），数据库会立刻抛出类似Subquery returns more than 1 row的错误。这不是警告，是硬性中断——报表根本跑不起来。
常见写法陷阱：
- 字典表没加主键或唯一约束，导致多个相同
code值存在 - 子查询里用了
LIKE或模糊条件，意外匹配多条 - 忘记关联主表字段，写成
(SELECT name FROM dict_type)这种无条件全表查
正确姿势：子查询必须带明确等值关联，且字典表code字段建议建唯一索引。
MySQL 8.0+ 用LEFT JOIN替代标量子查询更稳
虽然标量子查询写法简洁，但实际报表中字段一多（比如要拼5个字典描述），每个都套一层子查询，MySQL优化器容易放弃使用索引，执行计划里常出现DEPENDENT SUBQUERY，性能断崖式下跌。
更推荐提前LEFT JOIN字典表：
SELECT t.id, t.status, d1.name AS status_name, t.category, d2.name AS category_name FROM order_table t LEFT JOIN dict_status d1 ON d1.code = t.status LEFT JOIN dict_category d2 ON d2.code = t.category;
优势：
- 一次扫描字典表，避免重复查找
- 可利用
ON条件上的索引加速 - NULL值语义清晰（没匹配上就是
NULL，不用额外COALESCE兜底）
COALESCE和CASE WHEN处理字典缺失场景
真实业务里，主表字段可能存了废弃或未录入字典的值（比如status = '999'），标量子查询会返回NULL，但报表常要求显示“未知”或空字符串。
别在子查询里硬加COALESCE，那会让子查询无法走索引；应该在最外层处理：
SELECT id, COALESCE((SELECT name FROM dict_status WHERE code = t.status), '未知') AS status_name FROM order_table t;
或者更可控地用CASE WHEN：
SELECT
id,
CASE
WHEN t.status IN ('0', '1', '2') THEN (SELECT name FROM dict_status WHERE code = t.status)
ELSE '其他状态'
END AS status_name
FROM order_table t;
注意：IN列表不能太长，超过几百项就该考虑改用JOIN方式。
PostgreSQL 和 SQL Server 的标量子查询语法差异
MySQL允许子查询在SELECT列表里直接写，但PostgreSQL对子查询返回值更严格——必须显式用LIMIT 1防止多行（即使逻辑上不可能）：
SELECT id, (SELECT name FROM dict_status WHERE code = t.status LIMIT 1) AS status_name FROM order_table t;
SQL Server则要求子查询必须加括号，且不支持LIMIT，得用TOP 1：
SELECT id, (SELECT TOP 1 name FROM dict_status WHERE code = t.status) AS status_name FROM order_table t;
跨数据库迁移报表SQL时，这几个关键字最容易漏改，一跑就报错。
字典描述拼接看着简单，但一旦涉及性能、NULL处理、跨库兼容，每个环节都卡在细节上。尤其是子查询里少写一个等号，或者字典表缺索引，报表定时任务就可能从秒级变成分钟级。
