标量子查询在比较运算符右侧、select列表、变量赋值、update set等标量上下文中必须返回单值，否则直接报错；同一子查询移至in或exists后即合法，因属集合上下文。
标量子查询返回多行会直接报错，不是数据库“太严格”，而是 SQL 语义强制要求：它必须在一个需要单值的上下文中提供唯一结果。绕不过，也压不住——加 LIMIT 1 不是修复，是掩耳盗铃。
标量子查询在哪种上下文里会被判死刑？
只要子查询被放在需要「一个值」的地方，MySQL 就会在执行前静态检查其是否可能返回多行。一旦确认 ≥2 行，立刻中止并抛出 Subquery returns more than 1 row。这些位置包括：
-
WHERE col = (SELECT ...)—— 比较运算符右侧 -
SELECT (SELECT name FROM dept WHERE id = u.dept_id) AS dept_name—— SELECT 列表中独立一列 -
SET @x = (SELECT id FROM t WHERE ...)—— 变量赋值右侧 -
UPDATE users SET status = (SELECT default_status FROM config)—— SET 赋值表达式
注意：同一个子查询，挪到 IN 或 EXISTS 后面就合法了——因为那属于集合上下文，不是标量。
为什么 LIMIT 1 不是解法，而是隐患放大器？
加 LIMIT 1 能让语句跑通，但代价是放弃语义确定性。它不解决“为什么多行”，只掩盖“现在先取一个”。常见风险：
- 没
ORDER BY的LIMIT 1结果不可控：InnoDB 存储顺序、页分裂、版本升级都可能导致每次返回不同行 - 业务上本应唯一（如
user_id对应唯一头像），却因漏写关联条件导致全表扫描，LIMIT 1只是把数据错误变成随机错误 - 在存储过程中用
SET @x = (SELECT id FROM t WHERE ...)，平时数据干净不报错，某天脏数据入库就崩，且难以复现
真正该做的是：从写第一行子查询开始，就明确回答三个问题——它是否必须单值？谁来保证唯一性？不满足时怎么兜底（NULL？默认值？报错？）
正确防御方式：按场景选结构，不硬扛
别纠结“怎么让子查询变单行”，先看业务要什么：
- 想查「某个用户自己的字段」→ 补全关联条件：
(SELECT meta_value FROM user_meta um WHERE um.user_id = u.id AND um.meta_title = 'phone') - 想判断「是否存在匹配」→ 改用
EXISTS：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid') - 想查「属于某集合」→ 改用
IN：WHERE category_id IN (SELECT id FROM categories WHERE type = 'active') - 想取聚合值（最新/最高/计数）→ 用聚合函数：
(SELECT MAX(created_at) FROM logs WHERE user_id = u.id)
最常被忽略的一点：错误往往不出现在子查询本身，而出现在你没意识到它正被当做一个“值”来用。比如视图定义里嵌了一个看似无害的 (SELECT COUNT(*) FROM ...)，一旦底层表被删行或权限变更，整个视图就失效——而你可能半年后才第一次调用它。
