MySQL在ORDER BY无法利用索引且中间结果集未超tmp_table_size与max_heap_table_size较小值时，会用内存临时表排序；其本质是物化表达式、RAND()或聚合后结果，再以rowid模式排序，超限时自动落盘。
MySQL什么时候会用内存临时表做排序
当 ORDER BY 无法利用索引完成排序，且中间结果集大小未超过 tmp_table_size 和 max_heap_table_size 中的较小值时，MySQL 就会创建内存临时表来辅助排序。典型场景包括：ORDER BY RAND()、ORDER BY 表达式（如 ORDER BY LENGTH(name)）、多字段排序但无对应复合索引、或 SELECT 返回列宽较大但排序键较窄等。
为什么优先选内存临时表而不是直接 sort_buffer 排序
内存临时表和 sort_buffer 是两类不同机制：前者是完整数据暂存结构（带字段定义、可建索引），后者只是纯内存中的排序缓冲区（只存排序键+行标识）。MySQL 选择内存临时表，往往是因为排序逻辑无法被 sort_buffer 单独承载，比如：
-
RAND()需为每行动态计算并持久化随机值，而sort_buffer不支持“计算后暂存再排序”这种两阶段流程 - 排序字段是表达式或函数结果（如
UPPER(name)），必须先物化，否则无法稳定参与比较 - 涉及
DISTINCT+ORDER BY或GROUP BY+ORDER BY的组合，需先去重/聚合，再排序——这天然需要一个中间表
内存临时表排序实际走的是 rowid 模式
很多人误以为“内存临时表 = 全字段排序”，其实恰恰相反：对内存临时表，MySQL 优化器默认选用 <sort_key rowid></sort_key> 的 rowid 排序模式。原因很实在：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 内存临时表本身没索引，全字段排序意味着把所有字段都塞进
sort_buffer，浪费空间 - 回表成本极低——内存中按位置直接取行，不触发磁盘 I/O，所以“少存点、多查几次”更划算
- 例如
SELECT word FROM words ORDER BY RAND() LIMIT 3，临时表只存R（double）和W（varchar），sort_buffer只存R和内存地址偏移，排序完再按偏移取W
容易忽略的性能拐点：内存不够就落盘
内存临时表不是永远在内存里。一旦其实际占用超过 tmp_table_size（默认 16MB）与 max_heap_table_size 的较小值，MySQL 会自动把它转成磁盘临时表（InnoDB 引擎），这时 Using temporary; Using filesort 就真变成磁盘排序了。
你得盯着两个状态变量：Created_tmp_tables（总临时表数）和 Created_tmp_disk_tables（落盘次数）。如果后者增长快，说明排序正从“毫秒级”滑向“百毫秒级”。这时候不是调大参数就完事——要先确认是不是 RAND() 或表达式排序这类本就不该出现在 OLTP 查询里的写法。
