答案：优化ORDER BY需利用覆盖索引避免排序，如为WHERE和ORDER字段建立复合索引（city, age），确保执行计划显示Using index；优先将等值条件字段放索引前部，范围查询后难排序；用LIMIT减少排序量；避免对排序字段使用函数，可改用生成列加索引；通过EXPLAIN检查Using filesort和Using temporary以调整策略。
在MySQL中，ORDER BY 是常见的查询操作，但处理不当容易导致性能问题，尤其是在数据量大的情况下。优化 ORDER BY 的核心在于减少排序开销、合理使用索引以及避免全表扫描。
1. 使用覆盖索引避免文件排序
当查询的字段和排序字段都能被同一个索引覆盖时，MySQL可以直接利用索引顺序返回结果，无需额外排序（即避免 Using filesort）。
例如，有如下查询：
SELECT name, age FROM users WHERE city = 'Beijing' ORDER BY age;如果存在复合索引 (city, age)，MySQL 可以：
- 用 city 过滤数据
- 直接按 age 有序读取，跳过排序步骤
确保执行计划中显示 Using index 而不是 Using filesort，可通过 EXPLAIN 验证。
2. 合理设计复合索引支持排序
ORDER BY 字段应尽量作为索引的一部分，尤其是与 WHERE 条件结合使用时。
规则建议：
- WHERE 中的等值条件字段放在复合索引前部
- ORDER BY 字段紧随其后
- 避免对非等值条件（如范围查询）后的字段排序
例如：
SELECT * FROM orders WHERE user_id = 100 ORDER BY created_at;应创建索引：(user_id, created_at)。但如果写成 WHERE user_id > 100 ORDER BY created_at，由于 user_id 是范围查询，created_at 无法有效利用索引排序，可能仍需 filesort。
3. 控制排序数据量，避免大结果集排序
排序的代价随数据量增长呈非线性上升。应尽量通过 LIMIT 限制参与排序的行数。
例如：
SELECT * FROM logs ORDER BY timestamp DESC LIMIT 10;即使没有索引，LIMIT 10 能显著降低排序成本。若配合索引更好。
注意：不要在无 LIMIT 的情况下对百万级表做 ORDER BY，否则即使有索引也可能因回表或临时表导致慢查询。
4. 避免使用函数或表达式影响索引排序
对排序字段使用函数会破坏索引的有序性。
错误示例：
SELECT * FROM users ORDER BY UPPER(name);正确做法是存储规范化的值（如统一转大写），或使用生成列加索引（MySQL 5.7+）：
ALTER TABLE users ADD name_upper AS (UPPER(name));CREATE INDEX idx_name_upper ON users(name_upper);
基本上就这些。关键点是让 MySQL 尽可能利用索引顺序输出，避免额外排序动作。通过 EXPLAIN 分析执行计划，关注是否出现 Using filesort 和 Using temporary，及时调整索引策略。不复杂但容易忽略。
