ORDER BY + LIMIT必须放在子查询内才真正生效，因优化器仅在子查询中同时存在二者时才会下推Top N剪枝；若仅外层排序，仍需全量扫描与排序。
FROM子句里套SELECT：为什么不能直接ORDER BY再LIMIT？
直接在外部查询写 ORDER BY created_at DESC LIMIT 10，但 WHERE 条件匹配几百万行时，MySQL 仍要先扫描全部符合条件的记录、全排序、再截断——这很慢。FROM 子查询的核心价值，是让优化器把过滤和排序“下推”到子查询内部执行，从而大幅减少中间结果集大小。
子查询必须带别名，否则语法报错
MySQL 和 PostgreSQL 都强制要求 FROM 中的子查询必须有别名，否则报错 Every derived table must have its own alias。这不是可选项，是硬性语法限制。
- ✅ 正确写法：
SELECT * FROM (SELECT id, title FROM posts WHERE status = 'published') AS t ORDER BY t.created_at DESC LIMIT 10 - ❌ 错误写法：
SELECT * FROM (SELECT id, title FROM posts WHERE status = 'published') ORDER BY created_at DESC LIMIT 10（缺别名）
ORDER BY + LIMIT 必须放在子查询里才真正生效
很多人以为把 ORDER BY 放在外部查询就够了，其实不然。只有把排序和分页逻辑放进子查询，才能让引擎提前裁剪数据。否则子查询返回全部匹配行，外部再排序仍是全量操作。
- ⚠️ 外部排序无效：
SELECT * FROM (SELECT id FROM posts WHERE status = 'published') AS t ORDER BY t.id DESC LIMIT 10—— 子查询没排序，t 可能返回上万行 - ✅ 子查询内排序有效：
SELECT * FROM (SELECT id FROM posts WHERE status = 'published' ORDER BY id DESC LIMIT 10) AS t—— 引擎可在索引上快速定位 Top 10 - 注意：PostgreSQL 对子查询中单独使用
ORDER BY（无 LIMIT）会警告“ORDER BY in subquery ignored”，MySQL 则静默忽略；所以务必搭配 LIMIT 或 OFFSET 使用
索引是否生效，取决于子查询 WHERE + ORDER BY 字段是否覆盖
即使用了子查询，如果 WHERE status = 'published' 和 ORDER BY created_at DESC 涉及的字段没有联合索引，依然要回表或文件排序。比如 status 有单列索引、created_at 也有单列索引，但两者组合查询时，优化器大概率只选其一，导致排序无法走索引。
- 推荐建联合索引：
CREATE INDEX idx_status_created ON posts (status, created_at) - 若还需查
title等字段，考虑覆盖索引：CREATE INDEX idx_status_created_title ON posts (status, created_at, title) - 用
EXPLAIN检查type是否为range或index，且Extra不含Using filesort或Using temporary
真正卡住性能的往往不是语法会不会写，而是子查询里漏了 LIMIT、忘了加别名、或者索引根本没覆盖排序字段——这三个点，线上慢查里反复出现。
