SQL中ORDER BY变慢主因是全表扫描、缺索引或磁盘排序；应建联合索引（如city,age）、调优sort_buffer_size、避免函数排序、改用游标分页，并通过EXPLAIN定位Using filesort。
SQL中ORDER BY变慢，通常不是排序操作本身的问题，而是它触发了全表扫描、缺乏有效索引、或被迫在内存外排序（磁盘临时文件）。关键在于理解数据库如何执行排序，以及哪些环节最容易成为瓶颈。
没走索引：最常见原因
当ORDER BY字段没有索引，或索引无法覆盖查询条件+排序字段时，数据库只能先取出所有符合条件的行，再统一排序。比如：
SELECT name, age FROM users WHERE city = 'Beijing' ORDER BY age;
如果只有city单列索引，数据库仍需扫描所有北京用户，再对结果集按age排序——数据量大时非常耗时。
✅ 建议：
- 为WHERE + ORDER BY组合建联合索引，顺序遵循“等值条件在前，排序字段在后”，例如(city, age)；
- 若还有SELECT字段需要避免回表，可加入常用查询列构成覆盖索引，如(city, age, name)；
- 注意区分ORDER BY a, b和ORDER BY a DESC, b ASC——索引方向需匹配（MySQL 8.0+支持混合方向，旧版本建议统一升序）。
排序缓冲区不足：触发磁盘排序
MySQL用sort_buffer_size控制单个查询可用的内存排序空间。若结果集太大，超出该值，就会把中间结果写入磁盘临时文件（/tmp或tmpdir），I/O开销剧增。
✅ 建议：
- 查看SHOW STATUS LIKE 'Sort_merge_passes';，数值持续上升说明频繁磁盘排序；
- 适当调高sort_buffer_size（注意是每个连接独占，不宜设得过大）；
- 更根本的解法仍是加索引，让排序在索引B+树上自然完成，无需额外排序步骤。
使用函数或表达式排序：索引失效
以下写法会让索引完全失效：ORDER BY UPPER(name)、ORDER BY created_at + INTERVAL 1 DAY、ORDER BY CONCAT(first_name, last_name)
数据库无法利用普通索引做函数计算后的排序，只能取全量数据再计算再排。
✅ 建议：
- 改用生成列（Generated Column）+索引（MySQL 5.7+、PostgreSQL）；
- 预计算并存入冗余字段，配合应用层维护一致性；
- 确实需动态处理时，评估是否能改用应用层排序（小结果集可行，大数据量慎用）。
分页深翻：OFFSET越大越慢
ORDER BY created_at LIMIT 10000, 20看似简单，但数据库仍要先排序出前10020行，再丢弃前10000行——排序成本随OFFSET线性增长。
✅ 建议：
- 改用游标分页（Cursor-based Pagination）：记录上一页最后一条的created_at和id，下一页查WHERE created_at >= ? AND id > ? ORDER BY created_at, id LIMIT 20；
- 对高频分页场景，考虑物化排序视图或定时预聚合；
- 避免无限制跳转（如“跳到第1000页”），前端限制最大页码或改用搜索/筛选替代。
不复杂但容易忽略：排序性能问题往往藏在执行计划里。每次遇到慢ORDER BY，先跑EXPLAIN看是否Using filesort，再结合key和Extra字段判断索引使用情况——这是定位根因最快的方式。
