子查询中使用LIMIT或TOP必须配合ORDER BY，否则结果不稳定且数据库行为各异；正确写法需确保排序字段具备唯一性保障并建立匹配索引。
子查询里写LIMIT或TOP必须配ORDER BY
不配ORDER BY的LIMIT或TOP在子查询中几乎总是失效的——它可能返回任意几行，且每次结果不同。数据库不保证无序结果的稳定性，哪怕表有主键、索引或刚插入的数据按时间递增。
PostgreSQL 直接报错：ERROR: subquery must have ORDER BY when using LIMIT；MySQL 可能忽略LIMIT改走全表扫描；SQL Server 虽语法允许，但结果未定义，优化器可能跳过排序逻辑。
- 错误示例：
SELECT * FROM (SELECT id, name FROM users LIMIT 5) t JOIN orders o ON t.id = o.user_id - 正确写法：
SELECT * FROM (SELECT id, name FROM users ORDER BY created_at DESC LIMIT 5) t JOIN orders o ON t.id = o.user_id - 若
created_at有NULL值，需显式处理：ORDER BY created_at DESC NULLS LAST（PostgreSQL）或ORDER BY IFNULL(created_at, '1970-01-01') DESC（MySQL）
ORDER BY字段顺序必须带唯一性保障
只按业务字段排序（如salary DESC）仍不够：当多个记录salary相同时，数据库可任意选行，导致子查询结果不稳定。
必须追加主键或唯一字段，让排序具备确定性：
- MySQL / PostgreSQL：
ORDER BY salary DESC, id ASC - SQL Server：
ORDER BY salary DESC, id ASC（TOP 5前必须有此结构） - 避免
ORDER BY salary DESC, RAND()这类伪随机写法——它破坏确定性，且无法走索引
嵌套子查询中LIMIT容易被外层条件“绕过”
子查询本意是取“最新10条启用日志”，但外层JOIN或WHERE把其中若干条筛掉了，最终结果既不是最新、也不满10条——这不是语法错误，而是语义断裂。
- 错例：
SELECT * FROM (SELECT id FROM logs WHERE status = 1 ORDER BY ts DESC LIMIT 10) t JOIN events e ON t.id = e.log_id WHERE e.type = 'error'→ 若只有3条匹配type = 'error'，结果只剩3行 - 正确做法一（同表过滤）：
WHERE status = 1 AND type = 'error'提到子查询内 - 正确做法二（跨表）：用
ROW_NUMBER() OVER (ORDER BY ts DESC)先编号，再外层WHERE rn <= 10 - 注意：
LEFT JOIN后加WHERE e.type = 'error'实际等价于INNER JOIN，但不会让子查询排序逻辑失效，只是业务语义变了
索引没建对，ORDER BY + LIMIT就白写
即使写了ORDER BY ts DESC LIMIT 10，若ts字段没索引，或索引顺序/覆盖不匹配，优化器仍会全表扫描，LIMIT起不到剪枝作用。
- 单字段排序：
INDEX(ts)或INDEX(ts DESC)（PostgreSQL支持降序索引） - 联合排序（如
ORDER BY score DESC, id ASC）：必须建INDEX(score DESC, id ASC)，而非INDEX(name, score) - 函数包装字段（如
WHERE YEAR(created_at) = 2025）会让ORDER BY created_at DESC无法走索引 - 检查执行计划：
EXPLAIN中type为ALL、rows接近全表行数，说明没走索引
真正卡住人的地方不在语法，而在“排序字段是否稳定”和“索引是否覆盖排序+过滤条件”这两个点。少一个，LIMIT就只是个摆设。
