MySQL 的 ORDER BY 实际按索引扫描或 Using filesort 分阶段执行：有匹配索引时直接有序输出，否则用 sort_buffer 排序；多字段逐级比较，NULL 默认最小，禁用序号 / 别名排序，LIMIT 前须确保索引覆盖。
ORDER BY 是怎么实际排序的？不是“查完再排”，而是分阶段执行
MySQL 的 ORDER BY 并非简单地把整张表查出来、再用内存或磁盘去“后处理排序”。它会根据执行计划，选择两种核心路径：走索引直接输出有序结果，或启用 sort_buffer 做额外排序（即 Using filesort）。
- 如果
ORDER BY字段有合适的索引（比如WHERE city = ? ORDER BY name，且存在(city, name)联合索引），MySQL 可能直接按 B+ 树叶子节点顺序扫描，无需额外排序 ——EXPLAIN中Extra显示Using index - 否则就会触发
Using filesort：MySQL 从满足WHERE条件的行中，把SELECT和ORDER BY涉及的字段（如name, age）批量读入线程私有的sort_buffer；若数据量超限（受sort_buffer_size控制），还会写临时文件、归并排序 - 注意：
ORDER BY的字段不一定要出现在SELECT列表里，但若没索引支撑，仍会进filesort，且可能多读无用列，拖慢性能
多字段排序的优先级和 NULL 处理很关键
多列排序不是“一起算权重”，而是严格按书写顺序逐级比较：先比第一列，相等再比第二列，以此类推。这点在分页、去重、报表汇总时极易出错。
-
ORDER BY department_id ASC, salary DESC：同一部门内工资高的排前面；不同部门之间只看部门 ID 升序，工资高低完全不影响跨部门顺序 - NULL 值默认被当作“最小值”处理（
ASC时排最前，DESC时排最后），但 MySQL 8.0+ 支持NULLS FIRST/NULLS LAST显式控制，例如：SELECT * FROM employees ORDER BY salary DESC NULLS LAST; - 别依赖“自然顺序”：如果第一列几乎都不同（比如主键），第二列排序根本不会生效，日志或监控里也看不出异常
用列位置或别名排序看似方便，但隐患明显
用数字序号（如 ORDER BY 3）或 SELECT 中定义的别名（如 AS annual_salary）来排序，代码可读性 高，但容易引发隐性错误。
- 列位置排序（
ORDER BY 3）对 SQL 结构极度敏感：一旦SELECT子句增删字段，序号就错位，查询结果可能完全不符合预期，且语法检查无法报错 - 别名排序要求别名必须在
SELECT中明确定义，且不能和原始列名冲突；某些旧版 MySQL 或中间件（如 ProxySQL）可能不支持别名排序 - 更稳妥的做法是：显式写出列名或表达式，哪怕稍长一点 ——
SELECT salary * 12 AS annual_salary FROM employees ORDER BY salary * 12 DESC;
LIMIT 配合 ORDER BY 时，性能陷阱比想象中深
写 ORDER BY …… LIMIT 10 很常见，但若没索引，MySQL 仍需对 ** 全部符合条件的结果 ** 完成排序，再取前 10 行 —— 数据量大时，sort_buffer 可能爆掉，甚至触发磁盘临时文件，响应时间陡增。
- 务必确保
ORDER BY字段（或其前缀）已建索引；联合索引要匹配过滤条件 + 排序字段，例如WHERE status = 'active' ORDER BY created_at DESC应建(status, created_at) - 避免在
ORDER BY中使用函数或表达式（如ORDER BY UPPER(name)），这会让索引失效，强制filesort - 如果只关心“最新 N 条”，且表有自增主键或时间戳，有时用
WHERE id > ? ORDER BY id DESC LIMIT N（配合游标分页）比全量OFFSET更高效
真正决定排序行为的，从来不是语法本身，而是索引结构、WHERE 条件与 ORDER BY 字段的匹配关系，以及 sort_buffer_size 这类运行时参数。查 EXPLAIN 看 Extra 字段，比背语法重要得多。
