标量子查询必须返回且仅返回一行一列，否则报错——这不是语法错误，而是语义冲突：当用于=、>、SET赋值或SELECT列表等标量上下文时，数据库拒绝执行逻辑上不成立的多值比较。
标量子查询被放在单值上下文里，不是语法错，是语义冲突
MySQL（以及 PostgreSQL、SQL Server 等）在遇到 =、!=、>、SET 赋值、或 SELECT 列表中直接嵌套子查询时，会强制要求该子查询返回且仅返回一行一列。这不是解析器“卡住了”，而是它明确拒绝执行一个逻辑上无法成立的操作：比如让数据库拿一个字段去跟三行结果做“相等”比较——它不知道比哪一行。
常见触发位置包括：
-
WHERE order_status = (SELECT code FROM dict WHERE type = 'order')—— 若字典表里 type='order' 有多个 code，立刻报错 -
SELECT id, (SELECT name FROM dept WHERE dept_id = user.dept_id) dept_name FROM user—— 若 dept 表中 dept_id 不唯一，就崩 -
SET @x = (SELECT id FROM log WHERE user_id = 123)—— 日志表里 user_id=123 有 5 条？直接中断
为什么单独执行子查询不报错，一嵌进去就崩？
因为标量子查询的“单行约束”只在**被用作标量表达式时才生效**。你把子查询单独贴进客户端执行，它只是普通查询，返回几行都 OK；但一旦放进 = 右边、SELECT 列表、或 SET 赋值位，SQL 引擎就切换到“标量模式”，开始做静态行数检查。
这个检查发生在执行前，不是运行时扫描后才发现——所以哪怕子查询实际只返回一行，只要优化器判断它**可能返回多行**（比如没索引、没 WHERE 限定、或关联条件缺失），某些版本（如 MySQL 5.7/8.0 在 UNION ALL 场景下）也会提前报 Subquery returns more than 1 row。
验证方法很简单：
- 复制子查询部分，去掉括号和外层结构，单独跑一遍：
SELECT code FROM dict WHERE type = 'order' - 加
COUNT(*)看真实行数：SELECT COUNT(*) FROM dict WHERE type = 'order' - 用
EXPLAIN看执行计划，确认是否标记为DEPENDENT SUBQUERY（相关子查询）还是SUBQUERY（非相关，只执行一次）
别急着加 LIMIT 1，先问三个问题
LIMIT 1 能绕过报错，但大概率埋雷。动手前必须确认：
- 业务上是否真允许“任意取一条”？比如查用户头像，取哪条都行；但查“最新订单时间”，不加
ORDER BY created_at DESC就LIMIT 1，结果不可控 - 子查询漏了外层关联字段吗？例如
(SELECT meta_value FROM user_meta WHERE meta_title = 'avatar')缺少user_id = team_request.user_id，这不是数据多，是逻辑写错了 - 有没有更语义清晰的替代？
IN替代=、EXISTS替代IN（防 NULL）、LEFT JOIN替代 SELECT 列表子查询——这些不是“技巧”，是把意图写进 SQL
真正容易被忽略的点：错误常不在子查询本身
很多开发者盯着子查询 WHERE 条件调半天，其实问题出在——它被放在了标量上下文里，而业务本意根本不是要单值。比如写存储过程时用 SET @x = (SELECT id FROM t WHERE ...)，平时数据干净不报错，某天因脏数据或逻辑变更导致多行，整个过程就中断。防护不该等报错才加，从第一行子查询开始，就要明确：它是否必须单值？由谁保证唯一性？不满足时返回 NULL 还是报错？要不要加 IFNULL 或兜底聚合？
