【MySQL-索引调优】09:Order By相关概念

PS:现在orders表中存在idx_user_id(user_id),idx_user_status(user_id, status),idx_remark(remark)三个索引,表数据量为10w行

1-where + order by

运行:

sql 复制代码
EXPLAIN SELECT * FROM orders WHERE user_id = 1 ORDER BY create_time;

结果为:

id select_type table partitions type possible_keys key key_len ref rows filtered Extra
1 SIMPLE orders ref idx_user_id,idx_user_status idx_user_id 9 const 9 100 Using filesort

分析:

  • key = idx_user_id :查询条件user_id = 1用到了user_id索引,能快速定位到该用户的所有订单
  • rows = 9:预估只需要扫描9行,说明索引过滤效果很好
  • Extra = Using filesort :这是重点:虽然索引帮你定位到了user_id=1的行,但排序字段是create_time,而这个字段不在索引里,所以 MySQL 需要额外做一次排序操作(filesort)。 "filesort"并不是一定写到磁盘,它可能在内存里完成,但总之是额外的排序步骤

如果后续优化的话,可以加上联合索引(user_id, create_time)

2-单独order by

运行:

sql 复制代码
EXPLAIN SELECT * FROM orders ORDER BY create_time;

结果为:

id select_type table partitions type possible_keys key key_len ref rows filtered Extra
1 SIMPLE orders ALL 99520 100 Using filesort

分析:

(create_time)没有索引,所以具体的流程是:

复制代码
全表扫描
   ↓
取出99520行
   ↓
按 create_time 排序

本质就是create_time字段排序了,还是要建立索引提高性能

3-order by + limit

常用Sql:

sql 复制代码
SELECT *
FROM orders
ORDER BY create_time DESC
LIMIT 20;

看起来只查:

复制代码
20条

但数据库仍然要:

复制代码
扫描全部数据
→ 排序全部数据
→ 取20条

还是要排序

4-order by + limit分页:

Sql:

sql 复制代码
SELECT *
FROM orders
ORDER BY create_time
LIMIT 10000, 10;

很多人以为数据库会:

复制代码
直接跳到第10000条
取10条

4-1.无索引的情况

ORDER BY create_time 会触发 全表扫描 + 排序。

数据量大时,排序需要额外的内存或磁盘临时空间(sort buffer / external sort)。

然后再应用 LIMIT 10000,10,意味着先排好所有 10w 行,再丢掉前 10000 行,只取 10 行。

复制代码
1. 扫描全表 10w 行(读取所有数据到内存)
2. 对 10w 行进行快速排序(O(N log N))
3. 取排序后的第 10001-10010 行
4. 返回 10 行

4-2.有create_time索引的情况

索引本身就是按 create_time 排序的(B+Tree)

查询可以直接在索引上顺序扫描,不需要额外排序

但是 LIMIT 10000,10 依然意味着要 从索引头开始扫描到第 10010 行,然后返回第 10001~10010 行

复制代码
1. 从索引树根节点开始,按 create_time 顺序遍历
2. 跳过前 10000 个索引条目(仍需"数"过去,但只读索引)
3. 取第 10001-10010 个索引条目
4. 根据这 10 个 id 回表取完整数据
5. 返回 10 行

所以优化点在于:省掉了排序操作,但不能跳过前 10000 行的扫描

4-3.总结

无索引:全表排序 → 丢弃前 10 000 → 取 10

有索引:索引顺序扫描 → 丢弃前 10000 → 取 10

优化效果:索引省掉了排序操作,因为索引本质就是排序的(B+Tree),避免了昂贵的排序,但 offset 大时仍然会有性能问题,因为要扫描很多行

PS:

  • 无索引情况,性能最差,直接用表数据(相当于全表访问)
  • 有索引,扫描到第 10010 行,仅回表10次
相关推荐
数据工匠老o21 分钟前
一张 5 亿行的表按月分区后,清理历史数据从几小时变成了几秒
数据库·sql
蒸鱼Yuzheng43 分钟前
Shader 指令成本回归:离线编译、设备权重与误报控制
ci/cd·性能优化·gpu·shader·vulkan
hwscom43 分钟前
几分钟开防护,SQL和XSS注入全被护卫神挡住
数据库·sql·xss
石小千1 小时前
Redis开启ACL认证
数据库·redis·缓存
Dxy12393102161 小时前
MySQL JSON 生成列索引原理、实战与坑点
mysql·adb·json
东风微鸣1 小时前
把 Tailscale 接进 Prometheus 监控
java·数据库·prometheus
wno7041 小时前
MYSQL 常用合并函数
android·数据库·mysql
东风微鸣1 小时前
一次断电引发的血案:Ubuntu 26.04 升级中断后的完整救援实录
数据库·ubuntu·postgresql
大侠归来1 小时前
事务能回滚吗?Pipeline 算事务吗?
java·数据库·oracle
临床数据科学和人工智能兴趣组1 小时前
字符串转换为句子风格
大数据·数据库·人工智能·r语言·r语言-4.2.1