rank()和row_number()在报表中慢是因为强制全量排序，即使只取Top 10也需处理全部数据；优化方法包括子查询加LIMIT、索引优化及缓存物化视图。
rank() 和 row_number() 在报表里为什么慢得反常
因为它们强制全量排序，哪怕你只想要前 10 名。数据库必须把整个结果集按 ORDER BY 跑完才能给每个行算出排名，中间结果无法截断。
- 如果报表只展示「Top 10 销售员」，但底层用了
rank() OVER (ORDER BY total_sales DESC)，数据库仍会扫描全部销售记录并排序——哪怕表有千万行 -
row_number()和rank()性能差异极小，别指望换函数能提速；真正卡点是窗口范围没收缩 - MySQL 8.0+、PostgreSQL、SQL Server 都存在同样问题；SQLite 的窗口函数更弱，容易直接 OOM
用子查询提前 limit 是最有效的提速手段
把「取排名」和「取数据」拆开：先用子查询拿到目标 ID 列表，再 join 原表补字段。这样排序只发生在小结果集上。
SELECT u.name, u.total_sales, r.rn FROM users u JOIN ( SELECT user_id, ROW_NUMBER() OVER (ORDER BY total_sales DESC) AS rn FROM sales_summary WHERE report_month = '2024-05' ORDER BY total_sales DESC LIMIT 100 ) r ON u.id = r.user_id;
- 关键在子查询里加
LIMIT—— 它让优化器知道「我最多要 100 行」，从而可能选择索引扫描而非全表排序 - 务必确保
WHERE条件能命中索引（比如report_month上建了复合索引(report_month, total_sales)） - 别在子查询外再套一层
ORDER BY，否则可能抵消掉内层LIMIT的优化效果
缓存 rank 结果比实时计算更可靠
报表里的排名变化其实不频繁，比如日销量榜每天只更新一次。与其每次查都重算，不如把结果存成物化视图或定时写入汇总表。
- PostgreSQL 可用
REFRESH MATERIALIZED VIEW CONCURRENTLY每日凌晨更新，查询时直接SELECT * FROM mv_daily_rank - MySQL 没原生物化视图，但可以用定时任务 +
REPLACE INTO summary_rank SELECT ... ORDER BY ... LIMIT 1000 - 缓存后要注意失效逻辑：如果允许用户查「任意日期」的排名，那就得按日期分区存储，不能只存最新一份
ORDER BY 字段没索引是隐形性能杀手
窗口函数的 ORDER BY 不走索引，但外层查询的 ORDER BY 会。很多人误以为只要写了 OVER (ORDER BY x) 就自动优化了，其实没用。
- 检查执行计划里有没有
Sort节点；如果有且 rows 数很大，说明正在内存/磁盘排序 - 给经常用于排名的字段单独建索引，比如
CREATE INDEX idx_sales_total ON sales_summary (total_sales DESC) - 复合条件如
WHERE dept = ? ORDER BY score DESC，索引要写成(dept, score DESC)，顺序不能错
真正难处理的是「动态排名维度」——比如用户可选按销售额、利润率、订单数排序。这种没法靠单个索引覆盖，得结合应用层缓存或预计算多张汇总表。不然每次切维度就是一次全量排序。
