标量子查询返回多行报错本质是语义冲突：标量上下文要求单值，而子查询返回≥2行即被拒绝执行；常见于SELECT列表、WHERE右侧、SET赋值等位置。
这个错误不是数据真的“多行”，而是 MySQL 在标量上下文里收到了 ≥2 行——它直接拒绝执行，不给你运行机会。最常见于 SELECT 列表、WHERE 右侧、SET 赋值这些要求单值的地方。
为什么加 LIMIT 1 有时管用，有时反而错得更隐蔽？
LIMIT 1 能绕过优化器的静态检查，但它不解决语义问题：你本意是否真只要“任意一行”？
- 如果子查询逻辑上应唯一（比如查字典表
item_id对应的item_name），但因缺失deleted_flag = 0或未限定dict_code导致匹配多行，LIMIT 1只是掩盖数据质量问题 - 无
ORDER BY的LIMIT 1结果不可控：MySQL 可能每次返回不同行，线上环境容易引发数据不一致 - 在
UNION ALL大查询中，MySQL 5.7/8.0 某些版本会误判标量子查询可能多行而提前报错，此时加ORDER BY show_order LIMIT 1是已验证有效的 workaround
IN、= ANY、聚合函数，哪个该优先选？
取决于你要表达的业务意图，不是语法能不能跑通。
- 想查“属于某类的所有记录” → 用
IN：WHERE status IN (SELECT code FROM dict WHERE type = 'order_status') - 想查“比子查询中任一值都大” → 用
> ANY：WHERE score > ANY (SELECT passing_score FROM exam_rules) - 想取确定的单值（如最新时间、最高金额）→ 用聚合：
(SELECT MAX(create_time) FROM log WHERE user_id = u.id) - 别用
= ANY替代IN：语义等价但可读性差，且部分旧版驱动解析异常
LEFT JOIN 替换标量子查询，真能彻底避开这个问题？
能，而且通常更快。但要注意关联条件和 NULL 处理。
- 原写法：
SELECT id, (SELECT name FROM dept WHERE dept.id = user.dept_id) dept_name FROM user - 改写后：
SELECT u.id, d.name dept_name FROM user u LEFT JOIN dept d ON u.dept_id = d.id - 关键点：
LEFT JOIN不会因d匹配零行或两行而报错；但若dept表中dept_id不唯一，仍可能产生笛卡尔膨胀 —— 这时要先确认业务是否允许一对多，或加GROUP BY u.id+ 聚合 - 性能差异明显：标量子查询对主表每行都执行一次，JOIN 是一次哈希或索引查找
真正容易被忽略的是：错误常不在子查询本身，而在你没意识到它被放在了标量上下文中。比如在存储过程里写 SET @x = (SELECT id FROM t WHERE ...)，哪怕平时只返回一行，一旦某天数据异常就崩。别等报错才加防护，从写第一行子查询开始，就该明确它是否必须单值、由谁保证、不满足时怎么兜底。
