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字段，比背语法重要得多。
