在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的性能可以提升几个数量级。
