子查询中直接使用LIMIT/TOP会报错，需改用派生表或窗口函数；例如用ROW_NUMBER() OVER(PARTITION BY category ORDER BY sales DESC)标序号，外层筛选rn≤3，兼容所有主流数据库。
子查询里用 LIMIT/TOP 会报错？先确认数据库类型
MySQL 和 PostgreSQL 支持 LIMIT，SQL Server 要用 TOP，Oracle 12c+ 才支持 FETCH FIRST。在子查询中直接写 LIMIT 5 或 TOP 5 多数会报错——比如 MySQL 报 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'，SQL Server 则拒绝在子查询中使用 TOP 而不带 ORDER BY。
真正能跑通的写法，得靠派生表（即把子查询包一层 FROM (SELECT ...)）或窗口函数。别硬套主查询的语法到子查询里。
用派生表 + JOIN 实现「每个分类取销量前3的商品」
这是最通用、兼容性最好的解法，所有主流数据库都支持。核心是把「按 category 分组取 top 3」的结果作为临时表，再和原表关联。
- 先写内层：按
category和sales排序，用变量（MySQL）或ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC)（通用）标出行号 - 外层只取
rn 的记录，再和原表 <code>JOIN拿完整字段 - 注意：如果存在并列销量（如两个商品都是 99），
ROW_NUMBER()会强制分先后，RANK()才保留并列，但可能返回超过 3 行
SELECT t1.*
FROM products t1
INNER JOIN (
SELECT id, category,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
FROM products
) t2 ON t1.id = t2.id AND t2.rn <= 3;WHERE 条件里嵌套子查询时，怎么避免「相关子查询性能爆炸」
比如想查「销售额高于本部门平均值的员工」，写成 WHERE salary > (SELECT AVG(salary) FROM emp e2 WHERE e2.dept_id = e1.dept_id) 是典型的相关子查询——外层每扫一行，内层就重算一次平均值，数据量稍大就卡死。
更稳的做法是预聚合：
- 用
JOIN预先算好各部门平均值：(SELECT dept_id, AVG(salary) avg_sal FROM emp GROUP BY dept_id) - 再和主表
JOIN后过滤：WHERE e1.salary > dept_avg.avg_sal - 或者改用窗口函数：
AVG(salary) OVER (PARTITION BY dept_id)，直接在 SELECT 中计算，避免重复扫描
PostgreSQL / SQL Server 中用 CTE + 窗口函数更简洁
CTE 不仅可读性高，还能复用中间结果。比如「每个城市中价格最低的3个订单，且状态为 shipped」：
- 先在 CTE 里加过滤：
WHERE status = 'shipped'，缩小数据集再排序 -
ROW_NUMBER() OVER (PARTITION BY city ORDER BY amount ASC)标序号 - 主查询只
SELECT * FROM ranked_orders WHERE rn - 注意：
ORDER BY必须明确，否则ROW_NUMBER()结果不可预测；若城市量大，记得给city和amount建联合索引
WITH ranked_orders AS (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY city ORDER BY amount ASC) AS rn
FROM orders
WHERE status = 'shipped'
)
SELECT * FROM ranked_orders WHERE rn <= 3;多条件 Top-N 的本质不是拼语法，而是控制数据流路径：先过滤、再分组、后排序、最后截断。窗口函数比嵌套子查询直观，但老版本 MySQL（
