相关子查询通过主子查询关联实现每组top n：对主表每行，子查询统计同组中排序更优的记录数，若小于n则保留；需用联合索引、处理null和重复值，并注意性能瓶颈。
相关子查询怎么写才能正确限制每组的行数
直接用 GROUP BY 配合 LIMIT 是无效的——SQL 标准里 LIMIT 不能出现在分组语句中，更不能按组分别生效。相关子查询能绕过这个限制，核心是让子查询对主查询的每一行“动态计算其所在组内是否属于前 N 名”。
关键逻辑是：对当前行的分组字段（比如 category），在子查询中统计“同组中排序值优于或等于当前行的记录数”，若该数量 ≤ N，则保留该行。
- 必须用
WHERE关联主查询和子查询（如t2.category = t1.category），否则变成非相关子查询，结果全错 - 排序字段不能为
NULL，否则COUNT(*)统计可能漏行；建议提前用COALESCE(sort_col, '999999')填充 - 如果排序字段有重复值，可能出现某组返回 >N 行（并列情况），需额外加唯一键（如主键
id）破歧义
MySQL 5.7 / 8.0 下相关子查询取每组 Top 3 的典型写法
以商品表 products(category, price, id) 为例，取每个 category 中价格最高的前 3 个商品：
SELECT p1.category, p1.price, p1.id
FROM products p1
WHERE (
SELECT COUNT(*)
FROM products p2
WHERE p2.category = p1.category
AND (p2.price > p1.price OR (p2.price = p1.price AND p2.id > p1.id))
)
<p>注意括号里的双重条件：<code>p2.price > p1.price</code> 处理严格更高价，<code>(p2.price = p1.price AND p2.id > p1.id)</code> 确保相同价格时只算“id 更大的那些”，从而让当前行在并列中排进前 3。</p>
- MySQL 5.7 默认不支持窗口函数，这是最兼容的方案
- MySQL 8.0+ 推荐改用
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC, id)，性能好得多 - 子查询中别名（
p2）必须显式声明，不能省略
PostgreSQL 和 SQL Server 的等效写法差异在哪
PostgreSQL 对相关子查询优化较好，但语法上要求子查询返回标量，所以 COUNT(*) 写法通用；SQL Server 则要小心 TOP + ORDER BY 在子查询中的行为——它不支持直接嵌套 TOP 而不加 ORDER BY，且相关字段必须出现在子查询的 WHERE 或 JOIN 条件中。
- PostgreSQL 可直接复用 MySQL 示例，仅需确保排序字段索引存在（如
CREATE INDEX ON products(category, price DESC, id)） - SQL Server 更稳妥的方式是改用
NOT EXISTS结构：NOT EXISTS (SELECT 1 FROM products p2 WHERE p2.category = p1.category AND (p2.price > p1.price OR (p2.price = p1.price AND p2.id > p1.id)))，再配合外层计数逻辑 - 所有数据库中，若分组字段有大量重复值（如千万级同 category），相关子查询会严重慢——此时必须考虑物化中间结果或换用 CTE + 窗口函数
为什么相关子查询在大数据量下容易变慢
因为对主查询的每一行，都要执行一次完整子查询扫描；10 万行 × 每组平均 1000 行 = 十亿次比较。即使有索引，I/O 和 CPU 开销也远高于一次扫描 + 窗口函数。
- 务必给相关字段建联合索引，顺序必须匹配子查询
WHERE和ORDER BY条件（如(category, price DESC, id)） - 如果业务允许近似结果，可先用
DISTINCT ON（PostgreSQL）或TOP N WITH TIES（SQL Server）快速过滤，再补精度 - 真正上线前，在目标数据量级上用
EXPLAIN ANALYZE看子查询是否走了索引、是否触发临时表
相关子查询不是银弹，它只是没有窗口函数时的兜底手段；一旦数据库版本支持，优先替换为 ROW_NUMBER()，否则索引没建对、重复值没处理、排序字段含 NULL，都会让结果错得悄无声息。
