Using filesort表示MySQL无法利用索引有序性完成排序，必须额外启动内存或磁盘排序；根本原因包括WHERE范围查询破坏索引连续性、ORDER BY字段未匹配索引最左前缀、含函数或升降序不一致、COLLATE不统一等。
因为 MySQL 必须执行 Using filesort —— 这不是“可能慢”，而是明确放弃索引排序能力，转为内存或磁盘硬排序。
EXPLAIN 里出现 Using filesort 意味着什么
只要 EXPLAIN 的 Extra 列含 Using filesort，就表示：MySQL 无法用任何现有索引完成排序，必须把满足 WHERE 条件的行全部捞出来，再单独做一次排序。这个过程不走 B+ 树有序性，完全依赖 sort_buffer_size 和临时文件。
- 若结果集小、内存够，排序在内存完成，但 CPU 和 buffer 压力陡增
- 若结果集大（比如几万行）、
sort_buffer_size不足，就会写磁盘临时文件，触发多次Sort_merge_passes，IO 直接拉满 - 即使
type是ref或range，只要Extra含Using filesort，排序环节仍低效
为什么单列索引对多字段 ORDER BY 失效
复合排序（如 ORDER BY a, b, c）要求索引字段顺序严格一致。索引 (a, b, c) 可以支持，但 (a, c, b)、(b, a, c) 或三个单列索引都无效。
- MySQL 只能利用索引的“最左前缀连续段”做排序；断开即失效
- 例如查询
WHERE shop_id = 100 ORDER BY status, created_at，索引(shop_id, status, created_at)有效；但(shop_id, created_at, status)中status不在连续前缀里，排序仍走filesort - 范围查询（
>、BETWEEN、IN多值）后的字段无法参与排序，如WHERE amount > 100 ORDER BY user_id，索引(amount, user_id)中user_id部分不用于排序
ORDER BY 字段上用了函数或表达式
一旦写成 ORDER BY UPPER(name)、ORDER BY DATE(created_at) 或 ORDER BY score + 1，普通索引完全失效——MySQL 无法预知计算后值的顺序。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- MySQL 8.0+ 支持函数索引，可建
CREATE INDEX idx_name_upper ON users((UPPER(name))); - 更通用做法是冗余计算列：
ALTER TABLE users ADD COLUMN name_upper VARCHAR(255) STORED AS (UPPER(name));，再对其建普通索引 - 时间范围过滤别用
YEAR(created_at) = 2024，改用created_at >= '2024-01-01' AND created_at
字符集或排序规则（COLLATE）不一致
JOIN 或 WHERE 中涉及的字段如果 COLLATE 不同（比如一张表是 utf8mb4_0900_as_cs，另一张是 utf8mb4_unicode_ci），MySQL 无法安全比较，会强制退回到 Using filesort。
- 检查方式：在 Navicat 结构比对里看标红的
COLLATE差异 - 修复方法：显式统一
COLLATE，例如ORDER BY name COLLATE utf8mb4_unicode_ci，或直接修改字段定义 - 关键点：WHERE 字段、JOIN 字段、ORDER BY 字段三者的
COLLATE必须一致，否则隐式转换废掉整个索引路径
最常被忽略的是：没有 Using filesort 报错，SQL 照样返回结果，只是响应从毫秒变成秒级甚至分钟级；等你注意到时，这条语句可能已在生产环境跑了几个月。
