应优先用exists替代in判断存在性，因其语义明确、可走索引且天然去重；取最新记录须用row_number()窗口函数按用户分组、时间倒序编号后取rn=1，mysql 5.7等旧版本需用派生表或left join模拟。
IN 子查询在一对多场景下极易出错，别硬套——它只回答“有没有”，不控制“取哪条”。
用 EXISTS 替代 IN 判断存在性
查“有订单的用户”这类布尔型需求时，IN 看似简洁，但一旦子查询返回重复 user_id 或 NULL，结果就不可靠；EXISTS 语义明确、可走索引、且天然去重。
-
IN写法：SELECT * FROM users WHERE id IN (SELECT user_id FROM orders)—— 若orders表里user_id为空或含重复值，可能漏行或报错 -
EXISTS写法：SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)—— 每次只判断是否存在匹配行，不展开结果集 - MySQL 5.7 及更早版本对
IN子查询物化限制严，大结果集易触发ERROR 1205 (HY000): Deadlock found
取“每个用户的最新订单”别写相关子查询
SELECT u.name, (SELECT amount FROM orders o WHERE o.user_id = u.id ORDER BY created_at DESC LIMIT 1) FROM users u 这种写法是典型 N×M 复杂度：主表每行都触发一次子查询，数据量一上去就慢得明显。
- 正确姿势是用窗口函数：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC)——id加在ORDER BY末尾防并列排序导致rn不稳定 - 外层再
WHERE rn = 1即可拿到唯一最新记录 - MySQL 8.0+、PostgreSQL、SQL Server 支持；SQLite 不支持，得退回到
LEFT JOIN+ 聚合或应用层处理
LEFT JOIN + GROUP BY 时小心聚合陷阱
一对多用 LEFT JOIN 后接 GROUP BY 很常见，但聚合函数对 NULL 的行为容易被忽略。
-
COUNT(*)会把没订单的用户也计为 1（因为左表行还在），要判“是否有订单”必须用COUNT(o.id) > 0 -
STRING_AGG(o.item_name, ', ')或array_agg(o.item_name)在无匹配行时返回NULL，不是空字符串或空数组，业务代码必须COALESCE(..., '')或COALESCE(..., ARRAY[]::TEXT[]) - 若需保留用户全量，又想聚合订单字段，
GROUP BY u.id是必须的，且所有非聚合字段都要出现在GROUP BY中（MySQL 5.7 严格模式下）
MySQL 5.7 之前子查询性能差？用派生表绕过
旧版 MySQL 对 WHERE 中嵌套子查询优化能力弱，尤其多层嵌套时经常放弃索引，全表扫描。
- 坏写法：
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE status = 'paid') - 改成派生表：
SELECT u.* FROM users u INNER JOIN (SELECT DISTINCT user_id FROM orders WHERE status = 'paid') o ON u.id = o.user_id - 关键是把子查询提前物化成具名派生表（derived table），让优化器有机会对
o使用索引 - 注意加
DISTINCT或GROUP BY，避免派生表中重复user_id导致主表记录膨胀
真正麻烦的不是语法，而是“一对多”这个关系本身带来的粒度错位——子查询不带上下文，JOIN 不控数量，窗口函数又受限于版本。选哪种方案，得先看清你要的是“存在性”“最新一条”还是“聚合汇总”，再决定从哪儿切一刀。
