MySQL快速排序发生在server层执行器获取原始数据后的独立排序阶段，前提是sort_buffer足够容纳全部待排序数据且未触发磁盘临时文件（number_of_tmp_files=0）。
MySQL快速排序发生在什么阶段
快速排序只在 sort_buffer 足够容纳全部待排序行时触发，属于“内存内排序”（即 filesort 中的 in-memory phase）。它不是在存储引擎层执行，而是在 server 层、执行器拿到原始数据后启动的独立排序步骤。
常见错误现象：明明加了 ORDER BY，EXPLAIN 却没显示 Using filesort —— 实际是因为走了索引有序扫描，根本没进排序逻辑；反之，一旦出现 Using filesort，且 OPTIMIZER_TRACE 中 number_of_tmp_files = 0，基本可确认走的是快速排序。
- 触发前提：数据行数 × 每行参与排序的字段总长度 ≤
sort_buffer_size - 排序对象不是整行，而是按
sort_mode决定的字段组合（如<sort_key row_id></sort_key>或<sort_key full_row_data></sort_key>） - 不保证稳定性：MySQL 的快速排序实现是不稳定的，相同排序键的行相对顺序可能变化
快速排序用的是哪种快排变体
MySQL 源码中实际调用的是 std::sort（C++ STL），底层为 introsort（内省排序）：结合了快速排序、堆排序和插入排序。当递归深度超过阈值或子数组很小时自动切换策略，避免快排最坏 O(n²) 场景。
你无法通过 SQL 控制具体算法分支，但可以通过以下方式间接影响行为：
- 减小
max_length_for_sort_data值，促使 MySQL 选择row_id排序模式 → 减少单次排序的数据体积 → 更大概率留在内存中走快速排序 - 避免在
ORDER BY中使用函数或表达式（如ORDER BY UPPER(name)），否则无法利用索引，且表达式结果需额外计算和存储，增大 sort buffer 占用 - SELECT 列越少越好：全字段排序模式下，每多一个
VARCHAR(200)字段，就可能让几万行直接溢出sort_buffer，被迫切到归并排序
为什么有时看到“快速排序”却很慢
快排本身很快，但慢往往来自它前面或后面的环节——这才是容易被忽略的关键点。
-
sort_buffer是每个连接独占的，不是全局共享。并发高时大量连接同时分配几 MB 内存，可能引发系统内存压力甚至 swap，此时快排反而成为“压垮骆驼的最后一根稻草” - 即使排序在内存完成，如果用的是
row_id模式（即回表排序），排序后还要根据主键逐行回查聚簇索引，产生大量随机 I/O —— 这部分耗时远超快排本身 - 若
WHERE条件没走索引，server 层需先全表扫描读取所有行，再过滤，最后才排序。此时“快排”只是整个低效流程里最不拖后腿的一环
如何验证当前查询是否真正在用快速排序
不能只看 EXPLAIN，得结合 OPTIMIZER_TRACE 和状态变量交叉验证：
- 开启追踪：
SET optimizer_trace="enabled=on"，然后执行查询 - 查
information_schema.OPTIMIZER_TRACE，关注filesort_summary下的number_of_tmp_files：等于0才表示没写磁盘临时文件 - 查
sort_mode：若含packed_additional_fields，说明是全字段排序；若为sort_key, additional_fields，则是回表模式 - 对比
Innodb_rows_read和实际返回行数：如果前者远大于后者，说明扫描了大量无关行，排序只是表象，根源在过滤低效
真正卡住你的，往往不是快排算法本身，而是它被迫处理的数据量、来源路径和后续取数方式。盯着 sort_buffer_size 调参不如先看执行计划里有没有 Using where; Using filesort 并存——那才是问题真正的起点。
