报错时应按语义改用in或exists：=子查询多行说明本意是集合判断，硬加limit 1掩盖问题；in对null敏感，exists更安全；update/select子查询需显式关联外层字段确保单值。
WHERE 中用 = 匹配子查询报错，立刻换 IN 或 EXISTS
只要 WHERE 里写 = (subquery) 报错（比如 MySQL 的 Subquery returns more than 1 row），说明你本意就是“是否属于某集合”，不是“等于某一个值”。硬加 LIMIT 1 或 ROWNUM = 1 只会让结果不可控，还掩盖数据异常。
正确做法是按语义切换操作符：
- 想查“状态在审计日志里出现过的订单” → 改成
WHERE status IN (SELECT status FROM audit_log WHERE event_id = 123) - 想查“有未处理订单的客户” → 改成
WHERE EXISTS (SELECT 1 FROM orders WHERE customer_id = c.id AND status = 'pending') -
IN对 NULL 敏感：子查询返回NULL时整条条件判为UNKNOWN，该行被过滤；EXISTS不受 NULL 影响，更安全 - 别用
= ANY替代IN—— 功能等价但可读性差，且ANY在含 NULL 时行为更难预测
UPDATE 的 SET 右侧子查询多行，必须补关联或加聚合
UPDATE 的 SET column = (subquery) 要求子查询严格返回单值。报错不是语法问题，是语义冲突：数据库没法把一堆值塞进一个字段。
常见错误是漏掉外层表引用，比如写成：
UPDATE orders SET status_name = (SELECT name FROM statuses WHERE code = 'shipped')
看着没问题，但若本意是“每个订单按自己的 status_code 查名称”，却忘了关联：
- 错误写法：
SET status_name = (SELECT name FROM statuses WHERE active = 1)→ 扫全表，必然多行 - 正确写法：
SET status_name = (SELECT s.name FROM statuses s WHERE s.code = orders.status_code)→ 关联外层字段，自然唯一 - 如果真存在一对多（如一个
corp_key对应多个CORP_NAME），按业务选：ORDER BY updated_at DESC LIMIT 1（最新）、MAX(name)（最长名）、或GROUP_CONCAT(name)（拼接）
SELECT 列表里的标量子查询爆多行，别碰 DISTINCT，先补关联
像 (SELECT meta_value FROM user_meta WHERE meta_title = 'avatar') 这种写法，没限定 user_id，一查就是全表匹配——哪怕加 DISTINCT，只要不同用户设了不同头像，还是多行，照样报错。
DISTINCT 不是“变单行”的开关，它只去重，不减少行数。
- 正确做法：显式带上外层主表字段，比如
(SELECT um.meta_value FROM user_meta um WHERE um.user_id = team_request.user_id AND um.meta_title = 'avatar') - 如果某
user_id下没记录，结果自动为NULL，语义清晰 - 真要取最新一条？必须带
ORDER BY created_at DESC LIMIT 1；只写LIMIT 1是随机取，不同执行可能返回不同值 - MySQL 8.0+、PostgreSQL 支持
LATERAL/CROSS APPLY，但多数场景用关联子查询更直白、索引友好
用 LIMIT 1 前先问自己：业务真允许任意取一行吗？
LIMIT 1（MySQL/PG）或 TOP 1（SQL Server）能止住报错，但不解决“为什么多行”。生产环境用它，等于默认接受不确定性。
- 无
ORDER BY的LIMIT 1结果由存储引擎决定，可能随版本、数据分布、执行计划变化 - SQL Server 强制要求子查询里用
TOP 1必须配ORDER BY，否则语法报错 - 如果业务要的是“最高金额”，用
MAX(amount)比ORDER BY amount DESC LIMIT 1更稳——尤其当amount没索引时 - 聚合函数不是万能解药：
MAX(name)返回字典序最大字符串，和“最新设置的头像”完全不是一回事
最常被忽略的点：关联子查询是否真被数据库识别为相关子查询。用 EXPLAIN 看执行计划，确认它标记为 DEPENDENT SUBQUERY（MySQL）或 Correlated Subquery（PG），否则你写的“关联”只是假象。
