MySQL 5.7前不支持IN子查询中使用LIMIT，因优化器限制；SQL Server需用派生表或CTE包装TOP；PostgreSQL推荐ROW_NUMBER()窗口函数；跨库通用方案为两次查询或应用层分页。
MySQL里用子查询实现Top N为什么常出错
直接套用 SELECT * FROM t WHERE id IN (SELECT id FROM t ORDER BY score DESC LIMIT 5) 在 MySQL 5.7 及更早版本会报错：ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'。这不是语法写错了，是老版本引擎根本不允许在 IN 子查询里用 LIMIT。
根本原因在于：子查询执行顺序和优化器限制，LIMIT 属于结果集截断操作，而 IN 要求子查询返回完整可枚举集合。5.7 之前不支持这种组合。
- MySQL 5.7+、8.0 支持该写法，但需确认
sql_mode不含ONLY_FULL_GROUP_BY等干扰项 - PostgreSQL 和 SQL Server 完全不认这种写法，会直接报语法错误
- 即使能跑，
IN+ 子查询在大数据量下性能极差——引擎可能对主表每行都重跑一遍子查询
SQL Server的TOP N嵌套必须用派生表或CTE
SQL Server 不支持 LIMIT，也不允许在子查询中直接写 TOP 5，比如 WHERE id IN (SELECT TOP 5 id FROM t ORDER BY score DESC) 是非法的。必须把子查询包装成一个“有名字的结果集”才能引用。
正确做法只有两种：
- 用派生表：
SELECT * FROM t WHERE id IN (SELECT id FROM (SELECT TOP 5 id FROM t ORDER BY score DESC) AS tmp) - 用 CTE（推荐）：
WITH top5 AS (SELECT TOP 5 id FROM t ORDER BY score DESC) SELECT * FROM t WHERE id IN (SELECT id FROM top5)
注意：TOP 必须搭配 ORDER BY，否则结果不可控；如果 score 有重复，TOP 5 可能漏掉并列第5名的数据——这是业务逻辑盲点，不是 SQL 错误。
PostgreSQL里用窗口函数比子查询更稳
虽然 PostgreSQL 支持 LIMIT 子查询，但嵌套 IN 还是容易因数据类型隐式转换失败，比如子查询返回 integer，主表 id 是 bigint，就会报 operator does not exist: bigint = integer。
更可靠的做法是用 ROW_NUMBER() 窗口函数，在单次扫描中完成排序和截断：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY score DESC) AS rn FROM t ) ranked WHERE rn <= 5;
这个写法的好处：
- 避免子查询多次执行，IO 和 CPU 开销更低
- 类型安全：所有字段来自同一张表，不会出现隐式转换问题
- 可轻松扩展为“取每个分类 Top N”，只需把
PARTITION BY category加进OVER里
跨数据库通用写法其实只有两种可行路径
想写一次 SQL 在 MySQL、PostgreSQL、SQL Server 都跑通？别指望 LIMIT/TOP 嵌套能兼容。真正能落地的只有：
- 应用层分页：先查出全部 ID 排序后取前 N，再用
WHERE id IN (...)查详情——适合 N 很小（≤100）、ID 列有索引的场景 - 两次查询：第一次
SELECT id FROM t ORDER BY score DESC LIMIT 5（或等价写法），第二次拼接 ID 列表做主查询——注意防 SQL 注入，必须参数化
很多人忽略的是：所谓“Top N”在并发更新频繁的表里，本身就是一个瞬时快照。子查询执行完到主查询执行完之间，score 可能已被改写。如果业务要求强一致性，得加事务隔离或锁，而不是纠结 SQL 写法。
