标量子查询最稳妥但须确保单行单列，否则报ora-01427/mysql 1242；应通过聚合、limit/fetch first或lateral/apply优化，并加索引防全表扫描。
直接说结论：用 SELECT 中的标量子查询（scalar subquery）是最稳妥的方式，前提是子查询**必须返回且仅返回一行一列**，否则运行时报错。
子查询在 SELECT 列表里报错：ORA-01427 或 MySQL 1242
这是最常见现象——子查询查出多行，但 SELECT 列表里只允许单值。比如想查每个订单的客户等级，但某个客户对应了多条等级记录：
- 错误写法：
SELECT order_id, (SELECT level FROM customer_rank WHERE cust_id = o.cust_id) AS rank FROM orders o—— 如果customer_rank表对同一cust_id有两条记录，立刻崩 - 正确思路：先确保子查询逻辑上「天然唯一」，或加
LIMIT 1/ROWNUM = 1/FETCH FIRST 1 ROW ONLY（按数据库类型选） - 更安全的做法是提前聚合，比如用
MAX(level)或MIN(updated_at)明确语义
PostgreSQL / MySQL 8.0+ / SQL Server 支持相关性子查询，但 Oracle 要小心 ROWNUM
子查询里引用外部表字段（如 o.cust_id）叫相关子查询，主流数据库都支持，但语法细节差很多：
- MySQL 5.7 不支持在子查询里用
LIMIT配合相关字段，得套一层派生表；8.0+ 可以直接写(SELECT level FROM customer_rank cr WHERE cr.cust_id = o.cust_id ORDER BY eff_date DESC LIMIT 1) - PostgreSQL 推荐用
LATERAL替代嵌套子查询，性能更好，也更易读 - Oracle 里别直接写
WHERE ROWNUM = 1，它会在排序前截断——必须用子查询套ORDER BY+ROWNUM，或者改用FETCH FIRST 1 ROW ONLY（12c+）
性能隐患：标量子查询可能被重复执行，尤其在大结果集上
如果主查询返回 10 万行，而你写了 3 个独立的标量子查询，数据库很可能执行 30 万次子查询——不是 3 次。
- 观察执行计划，重点看
DEPENDENT SUBQUERY（MySQL）或SCALAR SUBQUERY出现次数 - 能用
JOIN代替就优先 JOIN，特别是当关联表数据量不大、且有合适索引时 - 实在要用子查询，确保子查询里的字段（如
cust_id）在被查表上有索引，否则全表扫一次就是灾难 - SQL Server 中可考虑用
APPLY替代，语义清晰且优化器更容易复用中间结果
最麻烦的其实是业务语义模糊的时候——比如“取最新一条等级”，没人告诉你 updated_at 是否唯一，也没人保证不会出现毫秒级重复。这时候光靠 SQL 很难兜住，得和业务方确认规则，再决定用 ROW_NUMBER() 还是加唯一约束，或者干脆前置到应用层处理。
