MySQL 5.7 中 ORDER BY 引发 CPU 飙升主因是全表扫描叠加 Using filesort，需通过 SHOW PROCESSLIST 和 EXPLAIN 定位 Sorting result 状态及 Extra 含 Using filesort 的 SQL，并建满足最左前缀、方向一致、无函数的联合索引（如 status, category, created_at）消除。
MySQL 5.7 中 ORDER BY 引发 CPU 飙升，大概率不是排序本身慢，而是触发了全表扫描 + 文件排序（Using filesort）+ 大量行比较，CPU 被迫反复做内存排序和临时结构维护。
查出哪些查询在用 ORDER BY 做文件排序
先确认是不是真有大量 Using filesort 在后台疯狂消耗 CPU：
- 执行
SHOW PROCESSLIST，重点看State列为Sorting result或Creating sort index的连接 - 对疑似 SQL 执行
EXPLAIN，检查Extra字段是否含Using filesort；如果type是ALL或index，基本坐实全表/全索引扫描 - 用
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%ORDER BY%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5找出耗时最高的带排序语句
ORDER BY 不走索引的常见原因
即使字段上有索引，ORDER BY 也可能失效 —— 这是 CPU 飙升最隐蔽的诱因：
- 排序字段和
WHERE条件字段未构成「最左前缀」：比如有索引(a, b, c)，但查询是WHERE a = ? ORDER BY c，c无法利用索引排序 -
ORDER BY含函数或表达式：ORDER BY UPPER(name)、ORDER BY created_at + INTERVAL 1 DAY，直接绕过索引 - 混合 ASC/DESC：
ORDER BY a ASC, b DESC，MySQL 5.7 对多列混合方向支持弱，常退化为 filesort - 排序字段类型与索引字段不一致：比如索引建在
VARCHAR(255)，但ORDER BY用了CAST(col AS CHAR)，隐式转换导致索引失效
让 ORDER BY 真正走索引的实操要点
目标是让 EXPLAIN 的 Extra 字段消失（即无 Using filesort），同时 type 达到 range 或更好：
- 建联合索引时把排序字段放在最后：例如常用
WHERE status = ? AND category = ? ORDER BY created_at DESC，就建INDEX idx_status_category_created (status, category, created_at) - 避免在排序字段上做任何计算；如必须格式化，改在应用层处理，或加生成列+索引（MySQL 5.7 支持虚拟生成列，但需注意版本补丁）
- 若必须混合方向排序，且数据量大，考虑拆成两个查询 + 应用层归并，比让 MySQL 硬扛更省 CPU
- 确认
collation一致性：ORDER BY字段的字符集和排序规则必须与索引定义完全一致，否则索引可能被忽略
innodb_buffer_pool_size 不够会放大排序开销
即使走了索引，如果缓冲池太小，MySQL 仍要频繁读盘加载索引页和数据页，导致逻辑读暴增、CPU 在 I/O 等待和页解析间反复切换：
- 检查当前设置：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，MySQL 5.7 下建议设为物理内存的 60%–75%，4 核 16GB 服务器至少配10G - 观察命中率：
SHOW STATUS LIKE 'Innodb_buffer_pool_read%';，若Innodb_buffer_pool_read_requests远大于Innodb_buffer_pool_reads（比如比值 - 不要只调大
innodb_buffer_pool_size就完事：它必须配合足够大的innodb_log_file_size（建议 ≥ 1G），否则重做日志频繁刷盘反而拖慢写入路径，间接影响读性能
真正难处理的不是单条 ORDER BY，而是那些被业务代码循环调用、每次只取 10 行却扫全表的“伪分页”查询——它们不会进慢日志，但 CPU 消耗是持续且隐蔽的。盯住 performance_schema 里的 digest 统计，比等 long_query_time 更早发现问题。
