Mysql orderby limit 索引命中规则

最新推荐文章于 2025-04-01 08:35:28 发布
最新推荐文章于 2025-04-01 08:35:28 发布
阅读量4.3k 收藏 4
点赞数 2
分类专栏： 数据库 文章标签： mysql orderby limit 索引 规则
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_40139740/article/details/84959075
版权
本文记录了一次SQL慢查询优化的过程，涉及MySQL 5.6.25版本。通过案例分析，解释了当ORDER BY子句前有范围查询时，如何选择合适的索引来提高查询效率。建议在编写SQL时使用EXPLAIN来检查和优化，以减少扫描行数并减轻数据库负担。同时提出了在代码层处理分页的方法，以避免在SQL中使用LIMIT时的性能问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

最近做的一个项目，发现了sql慢查询的情况，还好及时发现而且访问量并没有那么大，不然会造成很严重的事故，所以想记录一下，作为自己的成长记录，要不这脑子也不太好使记不住。

Mysql版本 5.6.25
表结构不展示啦 直接看索引 (公司的表不方便泄露 假如是table_name吧)
SHOW INDEX FROM table_name （列出索引信息）
在这里插入图片描述
问题sql （我是想通过questionId 进行排序 做分页处理 3475834代表上一页最大的questionId的值 ）
EXPLAIN
SELECT QuestionID FROM table_name
WHERE (CourseSectionID in(569743,508457) )
AND (QuestionID > 3475834)
ORDER BY QuestionID
LIMIT 50
在这里插入图片描述
发现rows 的值有 60多万 就是mysql扫表行数有这么多 好恐怖（为什么恐怖自己查去 本节不介绍恐怖原因） 使用的索引是QuestionID和CourseSectionID 的联合索引

优化sql
1.EXPLAIN
SELECT QuestionID FROM table_name
WHERE

最低0.47元/天 解锁文章
Mysql优化（二） -- order by及limit优化
weixin_39724194的博客
03-14 2675
数据： 给age和salary添加组合索引： order by order by的两种排序方式： FileSort：通过对返回数据进行排序，所有不是通过索引直接返回排序结果的排序都叫FileSort排序 using index：通过有序索引顺序扫描直接返回有序数据，不需要额外排序，操作效率高 FileSort优化： 通过创建合适的索引能够减少FileSort的出现，但是在某些情况下，条件限制不能让FileSort小时，那就需要加快FileSort的排序操作。对于FileSort，Mysql有两种排序
sql优化（结论，mysql）
chenwq726的博客
05-10 434
一、关联查询，主表的选择（Mysql优化器会进行优化） 备注：主表进行全表扫描，然后通过主键再找到其他表的数据，所以其他表会走主键索引（这里是用主键做关联查询） 1、where条件没有命中索引（可针对主表建对应的索引） 1.1、A，B表数据量相同（不走索引） 如果主键一样，则第一个表进行全表扫描，第二个表走主键索引 如果有联合主键，则有联合主键的表进行全表扫描，另一个表走主键索引 1.2、A，B表数据量不相同（不走索引） 如果主键一样，则数据量少的表进行全表扫描，数据量多的表走主键索引 如果
MySQL中ORDER BY与LIMIT一起使用（有坑）
wit_cx的博客
10-21 1万+
1. 现象与问题 ORDER BY排序后，用LIMIT取前几条，发现返回的结果集的顺序与预期的不一样 下面是我遇到的问题： 可以看到，带LIMIT与不带LIMIT的结果与我预期的不一样，而且“很不可思议”，真是百思不得其解 后来百度了一下，如果order by的列有相同的值时，mysql会随机选取这些行，为了保证每次都返回的顺序一致可以额外增加一个排序字段（比如：id），用两个字段来尽可能减少重复的概率 于是，改成 order by status, id; 问题虽然是解决了.
切记！MySQL中ORDER BY与LIMIT 不要一起用，有大坑
最新发布
sdujava2011
04-01 198
影响执行计划的一个因素是LIMIT，因此对于一个ORDER BY查询而言，带与不带LIMIT返回的行的顺序可能是不一样的。如果你只需要结果集中的指定数量的行，那么请在查询中使用LIMIT子句，而不是抓取整个结果集并丢弃剩下那些你不要的数据。可以看到，带LIMIT与不带LIMIT的结果与我预期的不一样，而且“很不可思议”，真是百思不得其解。ORDER BY排序后，用LIMIT取前几条，发现返回的结果集的顺序与预期的不一样。2、对于order by查询，带或者不带limit可能返回行的顺序是不一样的。
mysql 对索引limit_【业务学习】关于MySQL order by limit 走错索引的探讨
weixin_28787725的博客
01-21 257
Grape描述今天在跑脚本的时候发现了几条慢查询，根据之前的经验实属不应该，后来经过查找资料和分析出来结果，在这里简单记录一下。首先，我的sql是这个样子：select `id` from `xxx` force index(idx_d_t) where `date` = '2019-09-11' AND `time_flag` < '20190911220000' order by i...
MySQL的order by该如何避免“未命中索引“
陈哈哈的菜园子
05-30 3200
用Explain查看Order By语句执行计划时经常发现用不上索引，难道花好多时间和资源创建的联合索引都摆烂了？今天我把几个同学遇到的情况整理出来，做一个Order By使用索引的坑点分享。希望对你有用。
order by limit 造成优化器选择索引错误
渔夫数据库笔记
02-01 4454
1.order by limit 选错索引示例 在日常工作中，经常发现一些简单的查询语句因为加了 order by limit 造成优化器选择索引错误。例如如下sql(此处就不造数据了，只是列出一个sql示例) select * from test_table where name='xxxxx' order by id limit 1; #id 列为表的主键，name列有索引。有可能该查询最高效的路径应该是使用 name 索引访问，但是优化器最后却选择通过主键id进行扫描。这样就可能导致查询...
MySQL高频基本面试问题整理
热门推荐
张彦峰的博客
04-07 174万+
总结大厂MySQL高频基本面试问题整理，用于快速查缺补漏
【MySQL实战45讲10】MySQL为什么有时候会选错索引
RuaaaHaHa的博客
11-25 819
优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。如果使用索引 b 进行查询，那么就是扫描索引 b 的最后 50001 个值，与上面的执行过程相同，也是需要回到主键索引上取值再判断，所以需要扫描 50001 行。采样统计的时候，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。MySQL是通过采样统计来得到索引的基数的，虽然把整张表一行行统计，可以得到精确的结果，但是代价太高了，索引选择了采样统计。
Mysql索引
qq_57558631的博客
05-27 1846
mysql 索引分类 从物理存储角度分为： 聚簇索引：将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据 非聚簇索引：将数据与索引分开存储，索引结构的叶子节点指向了数据对应的位置 从逻辑存储角度分为： 普通索引：仅加速查询,无限制 唯一索引：加速查询 ，列值唯一（可以有null）,如果是组合索引，则列值的组合必须唯一 主键索引：加速查询 ，列值唯一（不可以有null），表中只允许有一个主键索引, 是一种特殊的唯一索引 组合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并..
order by、limit注入
newlife1441的博客
08-08 592
在学习sql注入的过程中我们不可避免要了解许多sql注入的相关注入语句，下面将介绍其中的两种注入方法order by、limit📔注入点出现在oder by后面即可称为order by 注入注入点出现在limit后面即可称为limit注入。...
mysql快速分页-索引性能分析-索引-order by-limit-offset-covering-index
ancienttale的专栏
12-31 3197
* 我们经常会碰到以下的场景  mysql中的用户数据(以下例子中以邮件为例)达到上百万级别，单个用户的邮件上万，  当进行用户邮件记录查询时需要支持按照时间，按照标题，和按照收件人进行排序，  排序之后还要分页显示（用户邮件可能会分上千页），当用户选择3000 页，5000页，  或者是尾页的时候，性能很差* 构造测试数据模型  表结构
order by limit使用介绍
weixin_30359021的博客
10-30 145
mysql> use test Database changed mysql> set names gbk; Query OK, 0 rows affected (0.02 sec) mysql> #在PHP中,获取不同栏目的商品 mysql> #在地址栏上获取$_GET['id'] mysql> select goods_id,cat_id,go...
MySQL联合查询,order by与LIMIT
Ghost Stories
03-23 2891
MySQL联合查询,order by与LIMIT
sql语句 order by 与 limit
王者生辉的博客
08-02 1万+
order by与limit： order by的用法 order by是用来写在where之后，给多个字段来排序的一个查询语句。 order by写法： 1. select 字段列表/* from 表名 where 条件 order by 字段名1 asc/desc, 字段名2 asc/desc,....... 2. select 字段列表/* from 表名 where 条件 order by 字段序号 asc/desc, 字段序号 asc/desc,....... （此时字...
sql注入之宽字节注入，limit，order by
H2223的博客
08-09 236
原理：宽字节注入发生的位置就是PHP发送请求到MYSQL时字符集使用character_set_client设置值进行了一次编码。在使用PHP连接MySQL的时候，当设置“character_set_client = gbk”时会导致一个编码转换的问题，也就是我们熟悉的宽字节注入宽字节注入是利用mysql的一个特性，mysql在使用GBK编码（GBK就是常说的宽字节之一，实际上只有两字节）的时候，会认为两个字符是一个汉字（前一个ascii码要大于128，才到汉字的范围）...
MYSQL基础之排序(ORDER BY)和分页(LIMIT)
u011863822的博客
12-18 4833
其实对数据的操作，必然会使用一个操作，就是排序。 ORDER BY(排序) 那就是这个关键字，先看演示。 -- 安装工资排序 SELECT empno, ename, job, mgr, hiredate, sal, comm, deptno FROM test.emp ORDER BY sal 当然这个也可以有多个字段 SELECT empno, ename, job, mgr, hiredate, sal, comm, deptno FROM test.emp ORDER BY sa
mysql 索引处理limit_mysql查询效率优化之 索引配合LIMIT 来最大化提高查询速度
weixin_42099302的博客
01-19 451
举例说明百万级或千万级数据表 添加索引来优化查询效率 并 配合 LIMIT 最大化提高查询效率，此方法仅限于返回的结果集庞大。本来条件下就最多返回几条或几十条 就没必要用这个方式来提升效率了。SELECT * FROM lqr_member WHERE username = ? and usertype= ?与SELECT * FROM lqr_member WHERE username...
SQL-order by 和 limit 用法
Ariel_欢
04-27 1万+
题目一：sql查找最晚一天，日期最大的一条记录 两种方法 例：查找最晚入职员工的所有信息 CREATE TABLE `employees` ( `emp_no` int(11) NOT NULL, --'员工编号' `birth_date` date NOT NULL, `first_name` varchar(14) NOT NULL, `last_name` varchar(16) NOT NULL, `gender` char(1) NOT NULL, `hire_date` date NOT
mysql的limit不走索引
12-29
### 解析 MySQL 的 `LIMIT` 不使用索引的原因 当执行带有 `ORDER BY` 和 `LIMIT` 的查询时，如果存在合适的索引，MySQL 应该能够高效地利用这些索引来加速查询。然而，在某些情况下，即使有可用的索引，性能仍然不佳。 主要原因是 MySQL 需要先按照指定列排序数据集，再应用 `LIMIT` 来获取前几条记录。这种操作模式可能导致大量随机读取，因为每次都需要通过索引找到对应的行位置并加载完整的数据页来验证条件匹配情况[^1]。 ```sql SELECT * FROM table_name WHERE condition ORDER BY column LIMIT offset, count; ``` 上述 SQL 查询会强制数据库引擎遍历整个表或部分分区的数据，并按给定字段排序之后才截取出所需数量的结果集。这使得即使是小范围内的检索也可能变得低效。 ### 如何优化以使 `LIMIT` 使用索引 为了提高此类查询效率，可以考虑以下几个方面： #### 创建覆盖索引（Covering Index） 创建一个包含所有需要返回字段在内的复合索引可以帮助减少回表次数。这样不仅减少了磁盘 I/O 开销，还提高了缓存命中率。 例如，对于如下查询： ```sql CREATE INDEX idx_cover ON table_name (creation_date, other_columns); ``` 这里的 `idx_cover` 是一个多列索引，它包含了用于排序的关键字 (`creation_date`) 及其他可能被 SELECT 子句请求到的列(`other_columns`) 。如此一来，只要满足一定条件下，MySQL 就可以直接从这个索引树中提取全部必要的信息而无需访问实际的数据文件[^3]。 #### 调整查询结构 有时重新设计查询逻辑也能带来显著改善。比如尝试将过滤条件提前处理掉一部分不符合要求的数据；或者采用子查询方式预先计算好偏移量(offset)，从而降低主查询的工作负担。 另外值得注意的是，TokuDB 这样的存储引擎提供了更好的压缩算法和支持更复杂的事务特性，或许可以在特定场景下提供优于默认 InnoDB 表现的选择[^2]。
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值