ORDER BY强制触发完整排序流程，本质是CPU和内存密集型任务；应通过EXPLAIN检查Using filesort（MySQL）、Sort节点（PostgreSQL）或Sort算子（SQL Server），并建匹配的复合索引避免全量计算后排序。
ORDER BY 强制触发排序操作，不是“加个子句”那么简单
它会让数据库引擎必须执行一次完整的排序流程——哪怕你只想要前10行，或者只是为窗口函数提供顺序。这个过程不依赖最终结果是否被用户看到，而是计算逻辑的硬性前提。MySQL 用 filesort，PostgreSQL 生成 Sort 节点，SQL Server 插入 Top N Sort，本质都是 CPU 和内存密集型任务。
没索引的 ORDER BY 在聚合查询里特别伤
聚合本身（如 COUNT、SUM）常能走索引扫描或流式聚合，但一旦加上 ORDER BY，引擎往往被迫先完成全部聚合再排序，无法提前截断或流式输出。常见踩坑点：
- 写
SELECT user_id, COUNT(*) FROM events GROUP BY user_id ORDER BY COUNT(*) DESC—— 即使有user_id索引，COUNT(*)结果仍需全量计算后排序 - 在
HAVING之后加ORDER BY，意味着过滤完才排，中间结果集可能远大于原始表 - 用表达式排序，如
ORDER BY UPPER(name)，不仅无法用索引，还额外增加字符串处理开销
窗口函数里的 ORDER BY 更隐蔽地拖慢性能
和查询末尾的 ORDER BY 不同，窗口函数中的 ORDER BY 是计算前提：没有它，ROW_NUMBER() 不知从哪开始编号，SUM() OVER () 不知累计顺序。这意味着：
- 即使只用
COUNT(*) OVER (PARTITION BY x)，也不该多写ORDER BY—— 它纯属冗余且强制排序 -
PARTITION BY a ORDER BY b要高效，得有联合索引(a, b)；只有a的单列索引，b排序照样走filesort - 重复值多时，
RANGE BETWEEN ...比ROWS BETWEEN ...开销高得多，因为要反复比对排序值是否“相等”
怎么判断是不是 ORDER BY 在拖慢聚合查询？
别猜，看执行计划：
- MySQL：
EXPLAIN输出中出现Using filesort或Using temporary，尤其在Extra列 - PostgreSQL：
EXPLAIN ANALYZE里看到高占比的Sort节点，或Sort Method: external merge（说明落盘了） - SQL Server：执行计划中出现
Sort算子，且 Estimated Operator Cost > 20%
真正容易被忽略的是：同一个字段，在 GROUP BY 里有索引，在 ORDER BY 里却因方向不一致（比如 GROUP BY created_at ASC 但 ORDER BY created_at DESC）而完全失效——索引没法双向利用。
