MySQL的limit和offset优化

最新推荐文章于 2023-09-21 17:45:25 发布

gengv

最新推荐文章于 2023-09-21 17:45:25 发布

阅读量5.5k

点赞数

分类专栏： SQL 文章标签： mysql null 优化 join email

本文链接：https://blog.csdn.net/gengv/article/details/5707323

版权

SQL 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

这两天在看关于MySQL分页查询的优化问题，看到网上的不少文章。

MySQL的分页查询通常都离不开limit帮忙，而其中的关键主要围绕以下两点：

1. 尽量减小limit的offset，即较小“limit m, n”里面的“m”。参考文章：http://www.fuchaoqun.com/2009/04/efficient-pagination-using-mysql/

2. 仅先定位offset的id，再查需要的limit数据。参考文章：http://www.sqlclub.cn/Optimi/2009-04/2626.htm

参考的这篇文章中，就是通过定位当前页的起止id，或者目标页的起止id，来先定位offset。但是也有一定的局限性，比如，当几次翻页的过程中，如果增加或者删除了数据，那么查询也许就不是最“实时”的了。不过通过第二点，我也想到一点，就是先查找需要的id，再根据id“按图索骥”，查得需要的记录。毕竟通常id都是索引或者主键，查询起来肯定效率高，而且仅查询id一个字段，应该更加快速。尤其是在查询的时候，需要重新排序的时候（当然是根据索引排序，否则慢死了）。

无意中翻看Baron Schwartz写的《高性能MySQL（第二版）》，其中4.5.5章节讲了如何优化LIMIT和OFFSET，也证实了这种方法。

我自己实验了几个例子：

例子1：

表t_attorney结构如下，具有30000行数据

两种查询方式：

mysql> select a.internalNo, a.firstName, a.lastName, a.email, a.address, a.telNo, a.certificateNo, a.nationality, a.idCardNo from t_ applicant a inner join (select id from t_ applicant order by id desc limit 18000,15) as a2 using(id) ;

15 rows in set (0.03 sec)

mysql> select a.internalNo, a.firstName, a.lastName, a.email, a.address, a.telNo, a.certificateNo, a.nationality, a.idCardNo from t_applicant a order by id desc limit 18000,15;

15 rows in set (0.08 sec)

两种查询方式，第一种查询平均耗时0.03秒左右；而第二种平均耗时0.08秒左右。

例子2：

表t_patentCase结构如下，具有90000行数据。

mysql> desc t_patentCase;
+-------------------+-------------+------+-----+---------+----------------+
| Field             | Type        | Null | Key | Default | Extra          |
+-------------------+-------------+------+-----+---------+----------------+
| id                | int(11)     | NO   | PRI | NULL    | auto_increment |
| internalNo        | varchar(45) | NO   | MUL | NULL    |                |
| name              | varchar(45) | YES |     | NULL    |                |
| appliedDate       | datetime    | YES |     | NULL    |                |
| createdDate       | datetime    | YES |     | NULL    |                |
| patentCaseType    | int(11)     | YES |     | NULL    |                |
| firstAttorney_id | int(11)     | YES | MUL | NULL    |                |
| secondAttorney_id | int(11)     | YES |     | NULL    |                |
| firstInventor_id | int(11)     | YES | MUL | NULL    |                |
| firstApplicant_id | int(11)     | YES | MUL | NULL    |                |
| firstContact_id   | int(11)     | YES | MUL | NULL    |                |
| applicationNo     | varchar(45) | YES |     | NULL    |                |
+-------------------+-------------+------+-----+---------+----------------+
12 rows in set (0.03 sec)

视图v_patentCase_summary是t_patentCase左连接另外4张表的结果视图，结构如下：

两种查询方式：

mysql> select v.id, v.internalNo, v.name, v.patentCaseType, v.createdDate, v.appliedDate, v.applicationNo, v.firstAttorney_id, v.firstAttorney_firstName, v.firstAttorney_lastName, v.secondAttorney_id, v.secondAttorney_firstName, v.secondAttorney_lastName, v.firstApplicant_id, v.firstApplicant_firstName, v.firstApplicant_lastName, v.firstInventor_id, v.firstInventor_firstName, v.firstInventor_lastName, v.firstContact_id, v.firstContact_firstName, v.firstContact_lastName from v_patentCase_summary v right join (select id from t_patentCase order by id desc limit 60000,15) as p on v.id=p.id ;

15 rows in set (1.45 sec)

? rows in set (??? sec)

两种查询方式，第一种查询平均耗时1.50秒左右；而第二种过了数分钟尚无反应。

小结：

通过以上两个例子可以看出这种方法的效率改善，当然优化无止境，根据以后的具体应用要求，还可以继续优化offset的定位问题。

gengv

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
MySQL的limit和offset优化

这两天在看关于MySQL分页查询的优化问题，看到网上的不少文章。MySQL的分页查询通常都离不开limit帮忙，而其中的关键主要围绕以下两点：1. 尽量减小limit的offset，即较小“limit m, n”里面的“m”。参考文章：http://www.fuchaoqun.com/2009/04/efficient-pagination-using-mysql/2. 仅先定位offset的id，再查需要的limit数据。参考文章：http://www.sqlclub.cn/Optimi/2009-04/
复制链接

扫一扫