ORDER BY 性能差异源于存储引擎数据组织方式不同：MyISAM 为索引+堆表，InnoDB 为聚簇索引；是否命中索引、触发 filesort 及覆盖索引使用情况才是关键，而非引擎本身。
ORDER BY 在 InnoDB 和 MyISAM 上为什么跑得不一样
因为存储引擎底层组织数据的方式不同：MyISAM 用的是“索引+堆表”，主键和数据物理分离；InnoDB 是聚簇索引，主键即数据，二级索引还带回表。排序时，如果 ORDER BY 字段没走索引，InnoDB 得先扫描聚簇索引再排序，MyISAM 可能靠文件顺序“碰巧快一点”——但这不可靠，纯看数据插入顺序。
真正影响性能的不是引擎名字，而是是否命中索引、是否需要 filesort、是否用到覆盖索引。别迷信“MyISAM 排序快”，它在高并发更新下锁表严重，实际场景中往往更慢。
哪些 ORDER BY 会触发 filesort（且无法避免）
filesort 是 MySQL 在内存或磁盘上做的额外排序步骤，一旦出现，基本意味着性能瓶颈。以下情况几乎必然触发：
-
ORDER BY字段未被任何可用索引覆盖（包括前缀匹配中断，比如索引是(a, b)，却写ORDER BY b） - 混合 ASC/DESC：
ORDER BY a ASC, b DESC，而索引是(a, b)（MySQL 8.0+ 支持降序索引，但老版本不行） - 对函数或表达式排序：
ORDER BY UPPER(name)、ORDER BY created_at + INTERVAL 1 DAY - 跨表 JOIN 后排序，且排序字段不在驱动表的索引覆盖范围内
检查是否触发 filesort，看 EXPLAIN 输出里的 Extra 列有没有 Using filesort —— 这比看引擎类型重要得多。
如何让 ORDER BY 走索引（InnoDB 尤其要注意）
InnoDB 对索引利用更严格，尤其涉及范围查询 + 排序时容易“断索引”。例如有联合索引 (status, created_at)，下面这些写法效果天差地别：
-
WHERE status = 'active' ORDER BY created_at→ 走索引，高效 -
WHERE status > 'active' ORDER BY created_at→status是范围，created_at无法继续用索引排序，大概率 filesort -
WHERE status IN ('active', 'pending') ORDER BY created_at→ MySQL 5.7 默认不优化为多个等值区间，也容易丢排序能力；8.0+ 有改进，但仍建议拆成 UNION 或加提示
实操建议：用 EXPLAIN FORMAT=JSON 看 used_key_parts 和 attached_condition，确认排序字段是否被真正用于索引扫描。
排序缓冲区（sort_buffer_size）调大有用吗
有用，但只在必须做 filesort 时起作用。它决定 MySQL 能在内存里排多少行，超过就落磁盘（变慢十倍以上）。但盲目调大有风险：
- 该参数是**每个连接独占**的，设成 32M，100 个并发连接就吃掉 3.2G 内存
- MyISAM 对 sort_buffer_size 利用率低，很多场景下不如优化索引来得直接
- InnoDB 更依赖
innodb_sort_buffer_size（仅用于创建索引），普通排序还是走通用sort_buffer_size
线上环境建议从 2M–4M 起步，配合 SHOW STATUS LIKE 'Sort%' 观察 Sort_merge_passes（落盘次数），大于 0 就说明 buffer 不够用；但优先级永远低于加索引或改查询逻辑。
最常被忽略的一点：ORDER BY 的字段类型要和索引字段完全一致。比如索引是 INT，但查询里写了 ORDER BY CAST(id AS CHAR)，索引直接失效——这种隐式转换不会报错，但性能雪崩。
