应为排序和过滤字段创建联合索引以提升ORDER BY + LIMIT查询效率。例如对user_id和created_at建立联合索引，使mysql能直接通过索引获取有序数据，避免全表扫描和文件排序，减少回表次数；若查询字段均包含在索引中，可进一步利用覆盖索引优化性能，通过EXPLaiN检查执行计划，确保无using filesort，从而实现高效分页查询。
在MySQL中，当使用ORDER BY和LIMIT进行排序并分页查询时，如果数据量较大，性能可能明显下降。合理使用索引可以显著提升这类查询的效率。关键在于让MySQL能通过索引直接获取有序数据，避免额外的排序操作和大量数据扫描。
理解ORDER BY + LIMIT的执行过程
MySQL在处理ORDER BY column LIMIT N这类语句时，理想情况是：
- 通过索引快速定位到排序后的前N条记录
- 无需对整个结果集排序
- 尽量减少回表次数（即访问主表数据）
如果缺少合适的索引，MySQL会先扫描所有匹配行，然后进行文件排序（filesort），最后取前N条，这在大数据集上非常低效。
为排序字段创建合适的索引
最直接的优化方式是为ORDER BY中的字段建立索引。
示例：
假设有一张文章表：
CREATE TABLE articles ( id INT PRIMARY KEY, user_id INT, created_at DATETIME, title VARCHAR(255) );
常见查询：
SELECT * FROM articles WHERE user_id = 123 ORDER BY created_at DESC LIMIT 10;
为了优化这个查询，应创建联合索引：
CREATE INDEX idx_user_created ON articles(user_id, created_at);
这样MySQL可以：
- 用
user_id快速过滤出目标数据 - 在索引内按
created_at有序读取前10条 - 仅对这10条记录回表获取完整数据
注意索引顺序与排序方向
联合索引的列顺序必须和查询条件匹配。一般规则是：
- 等值查询字段放前面（如
user_id = 123） - 排序字段放后面（如
created_at）
如果排序是DESC，MySQL也能利用索引的逆序扫描，所以不需要特别创建DESC索引（除非混合了ASC和DESC）。
不推荐：
只对created_at单独建索引，因为无法高效结合user_id条件。
覆盖索引进一步优化性能
如果查询的字段都能从索引中获取，就不需要回表，称为“覆盖索引”。
示例：
SELECT user_id, created_at, title FROM articles WHERE user_id = 123 ORDER BY created_at DESC LIMIT 10;
可使用覆盖索引：
CREATE INDEX idx_covering ON articles(user_id, created_at, title);
此时查询完全在索引中完成，速度更快。
避免全表扫描和临时表
使用EXPLAIN检查执行计划：
- 查看
type是否为ref或range - 确认
key使用了预期索引 - 检查
Extra是否有Using filesort，有则说明未走索引排序
出现Using filesort通常意味着需要补充或调整索引。
基本上就这些。核心是让索引同时支持过滤和排序，尽量减少数据访问量。只要设计好联合索引，ORDER BY + LIMIT的性能可以提升几个数量级。