TopN查询关键在于用索引完成排序和截断，需确保ORDER BY字段有有效索引且覆盖WHERE条件；避免函数导致索引失效，可物化计算字段或改用范围查询。
SQL 中的 TopN 查询，核心是“在满足条件的数据中，只取排序后前 N 条”。写得不好容易全表扫描、临时表膨胀、索引失效——性能直接掉一个量级。关键不是加 LIMIT，而是让数据库**用上索引完成排序和截断**。
用对 ORDER BY + LIMIT，且字段有索引
这是最基础也最容易翻车的一点。TopN 本质是“排序后取头”，所以 ORDER BY 的字段必须有有效索引，且该索引能覆盖查询需求（最好还能包含 WHERE 条件字段）。
- ✅ 推荐写法：SELECT id, name, score FROM user WHERE status = 1 ORDER BY score DESC LIMIT 10;
→ 若有复合索引 (status, score)，就能索引下推 + 索引有序扫描，查到 10 条就停，不回表也不排序。 - ❌ 危险写法：red">SELECT * FROM user ORDER BY create_time DESC LIMIT 10;
→ 没 WHERE 条件，又没索引在 create_time 上？全表扫描 + 文件排序，数据一多就卡死。
避免在 ORDER BY 中用函数或表达式
一旦 ORDER BY 出现函数（如 DATE(create_time)、UPPER(name)、score * 1.2），索引就基本失效——数据库无法利用索引的物理顺序做排序，只能走 filesort。
- ✅ 替代方案：提前物化计算字段并建索引。
比如要按“当天注册用户 Top10”，可加列 reg_date DATE GENERATED ALWAYS AS (DATE(create_time)) STORED，再建索引 (reg_date, id)。 - ✅ 或改写逻辑：用范围查询代替函数。
WHERE create_time >= '2024-06-01' AND create_time —— 能走索引，高效。
分页场景慎用 OFFSET（尤其大偏移）
“查第 999 页，每页 10 条”即 LIMIT 10 OFFSET 9990，数据库仍需扫前 9990 行，性能随偏移线性恶化。
- ✅ 游标分页（推荐）：
记录上一页最后一条的排序键值（如 last_score = 87.5），下一页写：
WHERE score —— 索引直接定位，O(1) 启动。 - ✅ 延迟关联（适用于需要 SELECT *）：
SELECT u.* FROM user u INNER JOIN (SELECT id FROM user WHERE status = 1 ORDER BY score DESC LIMIT 10) t ON u.id = t.id;
先用覆盖索引查 ID（快），再回表取全字段（少）。
聚合后取 TopN？优先用窗口函数
比如“每个部门工资最高的 3 人”，别用 GROUP BY + 子查询，易出错且难优化。
- ✅ 窗口函数清晰高效：
SELECT dept_id, name, salary, rn FROM (SELECT dept_id, name, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM emp) t WHERE rn - ⚠️ 注意：MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持；老版本需用变量或自连接，但维护性和性能都差。
