本文的目的是介绍SQL:使用LIMIT查询时计算匹配结果的数量的详细情况,我们将通过专业的研究、有关数据的分析等多种方式,同时也不会遗漏关于5个mysql优化limit查询语句总结、Error之sql
本文的目的是介绍SQL:使用LIMIT查询时计算匹配结果的数量的详细情况,我们将通过专业的研究、有关数据的分析等多种方式,同时也不会遗漏关于5个mysql优化limit查询语句总结、Error之sqlite中查询时的limit出错、mysql - 用php数组的array_slice分页和用limit查询分页哪个效率更高?、MYSQL / JSON:将数组与JSON格式的列列表进行比较,并计算匹配项的数量的知识。
本文目录一览:- SQL:使用LIMIT查询时计算匹配结果的数量
- 5个mysql优化limit查询语句总结
- Error之sqlite中查询时的limit出错
- mysql - 用php数组的array_slice分页和用limit查询分页哪个效率更高?
- MYSQL / JSON:将数组与JSON格式的列列表进行比较,并计算匹配项的数量
SQL:使用LIMIT查询时计算匹配结果的数量
假设users
我的MySQL DB中的表包含大量条目。
我需要遍历所有用户,但是我想一次仅执行大块操作(即使用LIMIT
和OFFSET
):
SELECT * FROM users LIMIT 100 OFFSET 200
是否有可能知道查询中匹配的用户总数,但仅返回LIMIT个用户?
换句话说,是否可以在不进行单独查询的情况下提前知道用户总数?
答案1
小编典典您可以使用SQL_CALC_FOUND_ROWS
和FOUND_ROWS()
在(几乎)一个查询中进行操作:
SELECT SQL_CALC_FOUND_ROWS * FROM users LIMIT 100 OFFSET 200;SELECT FOUND_ROWS();
尽管您仍然有两个结果集,但实际查询仅执行一次,从而避免了重复编码和可能浪费的CPU周期。
5个mysql优化limit查询语句总结
这篇文章主要介绍了
mysql的分页比较简单,只需要limit offset,length就可以获取数据了,但是当offset和length比较大的时候,mysql明显性能下降
1.子查询优化法
先找出第一条数据,然后大于等于这条数据的id就是要获取的数据
缺点:数据必须是连续的,可以说不能有where条件,where条件会筛选数据,导致数据失去连续性,具体方法请看下面的查询实例:
mysql> set profiling=1; Query OK, 0 rows affected (0.00 sec) mysql> select count(*) from Member; +----------+ | count(*) | +----------+ | 169566 | +----------+ 1 row in set (0.00 sec) mysql> pager grep !~- PAGER set to 'grep !~-' mysql> select * from Member limit 10, 100; 100 rows in set (0.00 sec) mysql> select * from Member where MemberID >= (select MemberID from Member limit 10,1) limit 100; 100 rows in set (0.00 sec) mysql> select * from Member limit 1000, 100; 100 rows in set (0.01 sec) mysql> select * from Member where MemberID >= (select MemberID from Member limit 1000,1) limit 100; 100 rows in set (0.00 sec) mysql> select * from Member limit 100000, 100; 100 rows in set (0.10 sec) mysql> select * from Member where MemberID >= (select MemberID from Member limit 100000,1) limit 100; 100 rows in set (0.02 sec) mysql> nopager PAGER set to stdout mysql> show profiles\G *************************** 1. row *************************** Query_ID: 1 Duration: 0.00003300 Query: select count(*) from Member *************************** 2. row *************************** Query_ID: 2 Duration: 0.00167000 Query: select * from Member limit 10, 100 *************************** 3. row *************************** Query_ID: 3 Duration: 0.00112400 Query: select * from Member where MemberID >= (select MemberID from Member limit 10,1) limit 100 *************************** 4. row *************************** Query_ID: 4 Duration: 0.00263200 Query: select * from Member limit 1000, 100 *************************** 5. row *************************** Query_ID: 5 Duration: 0.00134000 Query: select * from Member where MemberID >= (select MemberID from Member limit 1000,1) limit 100 *************************** 6. row *************************** Query_ID: 6 Duration: 0.09956700 Query: select * from Member limit 100000, 100 *************************** 7. row *************************** Query_ID: 7 Duration: 0.02447700 Query: select * from Member where MemberID >= (select MemberID from Member limit 100000,1) limit 100
从结果中可以得知,当偏移1000以上使用子查询法可以有效的提高性能。
2.倒排表优化法
倒排表法类似建立索引,用一张表来维护页数,然后通过高效的连接得到数据
缺点:只适合数据数固定的情况,数据不能删除,维护页表困难
倒排表介绍:(而倒排索引具称是搜索引擎的算法基石)
倒排表是指存放在内存中的能够追加倒排记录的倒排索引。倒排表是迷你的倒排索引。
临时倒排文件是指存放在磁盘中,以文件的形式存储的不能够追加倒排记录的倒排索引。临时倒排文件是中等规模的倒排索引。
最终倒排文件是指由存放在磁盘中,以文件的形式存储的临时倒排文件归并得到的倒排索引。最终倒排文件是较大规模的倒排索引。
倒排索引作为抽象概念,而倒排表、临时倒排文件、最终倒排文件是倒排索引的三种不同的表现形式。
3.反向查找优化法
当偏移超过一半记录数的时候,先用排序,这样偏移就反转了
缺点:order by优化比较麻烦,要增加索引,索引影响数据的修改效率,并且要知道总记录数 ,偏移大于数据的一半
limit偏移算法:
正向查找: (当前页 - 1) * 页长度
反向查找: 总记录 - 当前页 * 页长度
做下实验,看看性能如何
总记录数:1,628,775
每页记录数: 40
总页数:1,628,775 / 40 = 40720
中间页数:40720 / 2 = 20360
第21000页
正向查找SQL:
SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 839960, 40
时间:1.8696 秒
反向查找sql:
SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 788775, 40
时间:1.8336 秒
第30000页
正向查找SQL:
SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 1199960, 40
时间:2.6493 秒
反向查找sql:
SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 428775, 40
时间:1.0035 秒
注意,反向查找的结果是是降序desc的,并且InputDate是记录的插入时间,也可以用主键联合索引,但是不方便。
4.limit限制优化法
把limit偏移量限制低于某个数。。超过这个数等于没数据,我记得alibaba的dba说过他们是这样做的
5.只查索引法
MySQL的limit工作原理就是先读取n条记录,然后抛弃前n条,读m条想要的,所以n越大,性能会越差。
优化前SQL:
SELECT * FROM member ORDER BY last_active LIMIT 50,5
优化后SQL:
SELECT * FROM member INNER JOIN (SELECT member_id FROM member ORDER BY last_active LIMIT 50, 5) USING (member_id)
区别在于,优化前的SQL需要更多I/O浪费,因为先读索引,再读数据,然后抛弃无需的行。而优化后的SQL(子查询那条)只读索引(Cover index)就可以了,然后通过member_id读取需要的列。
以上就是5个
Error之sqlite中查询时的limit出错
错误图:
出错的语句:
Cursor cursor =db.query("user",null,"id DESC"," 2 offset 2");
解决方案1:
利用其他构造器,将后两个参数合并:
Cursor cursor =db.query("user","id DESC limit 2 offset 2");
解决方案2:
根据limit的源码:
Cursor cursor =db.query("user","2,3");//之间用逗号隔开且:偏移量,显示数量
mysql - 用php数组的array_slice分页和用limit查询分页哪个效率更高?
以前一直用的limit来分页,现在发现array_slice分页挺好用的,就是不知道效率会不会太低
回复内容:
以前一直用的limit来分页,现在发现array_slice分页挺好用的,就是不知道效率会不会太低
sql:select * from 表 limit m offset n.
这是正常的翻页的业务需求.
在一张count为200w的表上执行一下sql:
select * from 表 limit 1000000,5
立即学习“PHP免费学习笔记(深入)”;
执行时间:25s
问题:
MySQL里对LIMIT OFFSET的处理方式是,取出OFFSET+LIMIT的所有数据,然后去掉OFFSET,返回底部的LIMIT。
这种方式在offset很高的情况下,如:limit 100000,20,这样系统会查询100020条,然后把前面的100000条都扔掉,这是开销很大的操作,导致慢查询很慢.
如何优化:
用id>m limit n 取代,比用 limit m,n 快很多,原因在于与利用上了主键索引, 只查询了n条记录. 这种方法很适合数据加载,但是不一定适合前台的翻页场景,
因为ID可能不连续, 在电梯模式的翻页中不适用,只是用扶梯模式的翻页。
select * from 表 where id > 1000000 limit 5
执行一下:0.013s
还有一个简单的优化办法是使用覆盖查询(covering index)查询,然后再跟全行的做join操作。这样可以直接使用index得到数据,而不去查询表,当找到需要的数据之后,在与全表join,获得其他的列。
如:
select * from 表 inner join (select id from 表 limit 1000000,5) as lim on 表.id = lim.id
执行时间:0.211s
array_slice 分页?你确定要全部查出来在服务器分页,而不是在数据库中查询某一页的数据
MYSQL / JSON:将数组与JSON格式的列列表进行比较,并计算匹配项的数量
一个选项是从第一个成员(index-0)开始在JSON的整个键(JSON_EXTRACT()
)中迭代地选择(match_list
)数组的成员。直到数组的长度(JSON_KEYS()
)才能查找(JSON_LENGTH()
)JSON列(JSON_CONTAINS()
)中是否存在。我使用tags
来创建迭代,如以下查询所示:
information_schema.tables
Demo
关于SQL:使用LIMIT查询时计算匹配结果的数量的介绍已经告一段落,感谢您的耐心阅读,如果想了解更多关于5个mysql优化limit查询语句总结、Error之sqlite中查询时的limit出错、mysql - 用php数组的array_slice分页和用limit查询分页哪个效率更高?、MYSQL / JSON:将数组与JSON格式的列列表进行比较,并计算匹配项的数量的相关信息,请在本站寻找。
本文标签: