MySQL分页优化
最近，帮同事重写了一个MySQL SQL语句，该SQL语句涉及两张表，其中一张表是字典表（需返回一个字段），另一张表是业务表（本身就有150个字段，需全部返回），当然，字段的个数是否合理在这里不予评价。平时，返回的数据大概5w左右，系统尚能收到数据。但12月31日那天，数据量大概20w，导致SQL执行时间过长，未能在规定的时间内反馈结果，于是系统直接报错。
一般的思路是用MySQL的分页功能，即直接在原SQL语句后面增加LIMIT子句。但请注意，虽然你看到的反馈结果只是LIMIT后面指定的数量，于是想当然的以为MySQL只是检索了指定数量的数据，然后给予返回。其实，MySQL内部实现的原理是，检索所有符合where条件的记录，然后返回指定数量的记录。从这个角度来看，直接在原SQL语句后面添加LIMIT子句只能说是一种可以实现功能的方案，但未必最优。
具体在本例中，首先我们来看一下150个字段的表的统计信息：
一行大概就占2k，而Innodb默认页的大小为16k，这意味着，一个页中最多可存储8行的数据。随机读的可能性大大增加。而这无疑会对数据库系统的IO造成极大的压力。
优化前
如果采用上述方案，即直接在原SQL语句后面增加LIMIT子句，下面，我们来看看它的执行情况。
首先，直接添加LIMIT子句后的SQL语句如下（已省略a1表的150个字段和a2中的一个字段）：
FROM upay_csys_scquery_txn_log_his a1 LEFT JOIN upay_csys_trans_code a2 on(a1.int_trans_code=a2.trans_code) WHERE STATUS<>'00' AND settle_date=20151230 limit 50000,10000;
其执行时间如下：
大概执行了32s，绝大部分都花费到Sending data上了。Sending data指的是服务器检索数据，读取数据，并将数据返回给客户端的时间。
关于上述执行结果，有以下几点需要说明：
1. 这是SQL语句多次执行后的结果，这样就可以排除结果缓存的影响，事实上，每次查询的时长都是32s左右。
2. 为什么选用的是limit 50000,10000，而不是0，10000，这个主要是考虑到对于LIMIT子句来说，越到后面，分页的成本越高。基于此，选择了中间值来作为分页的结果。
该语句的执行计划如下：
优化后：
优化的思路：
只对该表的主键进行分页，然后用返回的主键作为子查询的结果，来检索该表其它字段的值。
改写后的SQL语句如下：
FROM upay_csys_scquery_txn_log_his a1 LEFT JOIN upay_csys_trans_code a2 on(a1.int_trans_code=a2.trans_code) where seq_id in (select seq_id from (select seq_id FROM upay_csys_scquery_txn_log_his a1 WHERE STATUS<>'00' AND settle_date=20151230 order by 1 limit 50000,10000) as t);
其执行时间如下：
大概3s多，比第一种方案快了差不多10倍，效果显著。
下面来看看其执行计划（explain extended）
总结：
1. 改写后的语句原本如下：
FROM upay_csys_scquery_txn_log_his a1 LEFT JOIN upay_csys_trans_code a2 on(a1.int_trans_code=a2.trans_code) where seq_id in (select seq_id FROM upay_csys_scquery_txn_log_his a1 WHERE STATUS<>'00' AND settle_date=20151230 order by 1 limit 50000,10000);
但MySQL报以下错误：
ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'
需再增加一个嵌套子查询，
比如这样的语句是不能正确执行的。
select * from table where id in (select id from table limit 12);
但是，只要你再加一层就行。如：
select * from table where id in (select t.id from (select * from table limit 12)as t)
这样就可以绕开limit子查询的问题。
问题解决。
2. 如果想查看MySQL查询优化器等价改写后的SQL语句，可首先通过explain extended得到具体的执行计划，然后通过show warnings查看。
具体在本例中，等价改写后的SQL语句如下：
与设想中的执行顺序一致~
3. 如何查看MySQL语句各步骤的执行时间。
以上就是本文的全部内容，希望对大家MySQL分页优化有所帮助。
相关推荐
-
mysql 分页优化解析
如果你的数据量有几十万条,用户又搜索一些很通俗的词,然后要依次读最后几页重温旧梦.mysql该很悲壮的不停操作硬盘. 所以,可以试着让mysql也存储分页,当然要程序配合.(这里只是提出一个设想,欢迎大家一起讨论) ASP的分页:在ASP系统中有Recordset对象来实现分页,但是大量数据放在内存中,而且不知道什么时候才失效(请ASP高手指点). SQL数据库分页:用存储过程+游标方式分页,具体实现原理不是很清楚,设想如果用一次查询就得到需要的结果,或者是id集,需要后续页时只要按照结果中的I
-
Mysql limit 优化，百万至千万级快速分页 复合索引的引用并应用于轻量级框架
MySql 这个数据库绝对是适合dba级的高手去玩的,一般做一点1万篇新闻的小型系统怎么写都可以,用xx框架可以实现快速开发.可是数据量到了10万,百万至千万,他的性能还能那么高吗?一点小小的失误,可能造成整个系统的改写,甚至更本系统无法正常运行!好了,不那么多废话了.用事实说话,看例子: 数据表 collect ( id, title ,info ,vtype) 就这4个字段,其中 title 用定长,info 用text, id 是逐渐,vtype是tinyint,vtype是索引.这是一个
-
MySQL中分页优化的实例详解
通常,我们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询.例如下面这个SQL: SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10; 或者像下面这个不带任何条件的分页SQL: SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10; 一般而言,分页SQL的耗时随着 start 值的增加而急剧增加,我们来看下面这2个不同起始值的分页SQL执行
-
如何优化Mysql千万级快速分页
看例子: 数 据表 collect ( id, title ,info ,vtype) 就这4个字段,其中 title 用定长,info 用text, id 是逐渐,vtype是tinyint,vtype是索引.这是一个基本的新闻系统的简单模型.现在往里面填充数据,填充10万篇新闻. 最后collect 为 10万条记录,数据库表占用硬盘1.6G. OK ,看下面这条sql语句: select id,title from collect limit 1000,10; 很快:基本上0.01秒就OK
-
在大数据情况下MySQL的一种简单分页优化方法
通常应用需要对表中的数据进行翻页,如果数据量很大,往往会带来性能上的问题: root@sns 07:16:25>select count(*) from reply_0004 where thread_id = 5616385 and deleted = 0; +----+ | count(*) | +----+ | 1236795 | +----+ 1 row in set (0.44 sec) root@sns 07:16:30>select id from reply_0004 wher
-
MySQL 百万级分页优化(Mysql千万级快速分页)
以下分享一点我的经验 一般刚开始学SQL的时候,会这样写 复制代码 代码如下: SELECT * FROM table ORDER BY id LIMIT 1000, 10; 但在数据达到百万级的时候,这样写会慢死 复制代码 代码如下: SELECT * FROM table ORDER BY id LIMIT 1000000, 10; 也许耗费几十秒 网上很多优化的方法是这样的 复制代码 代码如下: SELECT * FROM table WHERE id >= (SELECT id FROM
-
mysql limit分页优化方法分享
同样是取10条数据 select * from yanxue8_visit limit 10000,10 和 select * from yanxue8_visit limit 0,10 就不是一个数量级别的. 网上也很多关于limit的五条优化准则,都是翻译自MySQL手册,虽然正确但不实用.今天发现一篇文章写了些关于limit优化的,很不错. 文中不是直接使用limit,而是首先获取到offset的id然后直接使用limit size来获取数据.根据他的数据,明显要好于直接使用limit.这
-
MySQL分页优化
最近,帮同事重写了一个MySQL SQL语句,该SQL语句涉及两张表,其中一张表是字典表(需返回一个字段),另一张表是业务表(本身就有150个字段,需全部返回),当然,字段的个数是否合理在这里不予评价.平时,返回的数据大概5w左右,系统尚能收到数据.但12月31日那天,数据量大概20w,导致SQL执行时间过长,未能在规定的时间内反馈结果,于是系统直接报错. 一般的思路是用MySQL的分页功能,即直接在原SQL语句后面增加LIMIT子句.但请注意,虽然你看到的反馈结果只是LIMIT后面指定的数量,
-
MySQL优化案例系列-mysql分页优化
通常,我们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询.例如下面这个SQL: SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10; 或者像下面这个不带任何条件的分页SQL: SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10; 一般而言,分页SQL的耗时随着 start 值的增加而急剧增加,我们来看下面这2个不同起始值的分页SQL执行
-
mysql limit分页优化详细介绍
mysql limit分页优化 同样是取10条数据 select * from yanxue8_visit limit 10000,10 和 select * from yanxue8_visit limit 0,10 就不是一个数量级别的. 网上也很多关于limit的五条优化准则,都是翻译自MySQL手册,虽然正确但不实用.今天发现一篇文章写了些关于limit优化的,很不错. 文中不是直接使用limit,而是首先获取到offset的id然后直接使用limit size来获取数据.根据他的数据,
-
MYSQL分页limit速度太慢的优化方法
在mysql中limit可以实现快速分页,但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了,否则可能卡死你的服务器哦. 当一个表数据有几百万的数据的时候成了问题! 如 * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢,可以按照一下方法解决 第一页会很快 PERCONA PERFORMANCE CONFERENCE 2009上,来自雅虎的几位工程师带来了一篇"EfficientPag
-
MySQL分页Limit的优化过程实战
前言 在我们使用查询语句的时候,经常要返回前几条或者中间某几行数据,这个时候怎么办呢?不用担心,mysql已经为我们提供了这样一个功能. SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset LIMIT 子句可以被用于强制 SELECT 语句返回指定的记录数.LIMIT 接受一个或两个数字参数.参数必须是一个整数常量.如果给定两个参数,第一个参数指定第一个返回记录行的偏移量,第二个参数指定返回记录行的最大数目.初始记录行的偏移
-
浅谈mysql使用limit分页优化方案的实现
Mysql limit分页语句用法 与Oracle和MS SqlServer相比,mysql的分页方法简单的让人想哭. --语法: SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset --举例: select * from table limit 5; --返回前5行 select * from table limit 0,5; --同上,返回前5行 select * from table limit 5,10; --返回6
-
MySQL 分页查询的优化技巧
在有分页查询的应用中,包括 LIMIT 和 OFFSET 的查询十分常见,而且几乎每个都会有一个 ORDER BY 子句.如果使用索引排序的话将对性能优化十分有帮助,否则服务端需要做很多文件排序. 一个高频的问题是 offset 的值过大.如果查询类似 LIMIT 10000, 20,将会产生10020行,并将之前的10000行丢弃,这样的代价很高.假设所有的页使用相同的频次访问,这样的查询将平均扫描一半数据表.为了优化他们,你可以在分页视图中限制最多可访问的页数,或者让大便宜的查询更有效. 一