怎么提高MySQL Limit查询的性能
有个几千万条记录的表 on MySQL 5.0.x，现在要读出其中几十万万条左右的记录。常用方法，依次循环：
1
| 代码如下 | 复制代码 |
| select * from mytable where index_col = xxx limit offset, limit; |
|
经验：如果没有blob/text字段，单行记录比较小，可以把 limit 设大点，会加快速度。
问题：头几万条读取很快，但是速度呈线性下降，同时 mysql server cpu 99% ，速度不可接受。
调用
| 代码如下 | 复制代码 |
| explain select * from mytable where index_col = xxx limit offset, limit; | |
显示 type = ALL
在 MySQL optimization 的文档写到"All"的解释
A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that allow row retrieval from the table based on constant values or column values from earlier tables.
看样子对于 all, mysql 就使用比较笨的方法，那就改用 range 方式？ 因为 id 是递增的，也很好修改 sql 。
| 代码如下 | 复制代码 |
|
select * from mytable where id > offset and id < offset + limit and index_col = xxx |
|
explain 显示 type = range，结果速度非常理想，返回结果快了几十倍。
Limit语法：
1
| 代码如下 | 复制代码 |
| SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset |
|
LIMIT子句可以被用于强制 SELECT 语句返回指定的记录数。LIMIT接受一个或两个数字参数。参数必须是一个整数常量。
如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1)。
为了与 PostgreSQL 兼容，MySQL 也支持句法：LIMIT # OFFSET #。
| 代码如下 | 复制代码 |
| mysql> SELECT * FROM table LIMIT 5,10; //检索记录行6-15 |
|
//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为-1
| 代码如下 | 复制代码 |
|
mysql> SELECT * FROM table LIMIT 95,-1; //检索记录行96-last |
|
//如果只给定一个参数，它表示返回最大的记录行数目，换句话说，LIMIT n 等价于 LIMIT 0,n
| 代码如下 | 复制代码 |
| mysql> SELECT * FROM table LIMIT 5; | |
//检索前5个记录行
MySQL的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。同样是取10条数据，下面两句就不是一个数量级别的。
| 代码如下 | 复制代码 |
|
select * from table limit 10000,10 select * from table limit 0,10 |
|
文中不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据。根据他的数据，明显要好于直接使用limit。
这里我具体使用数据分两种情况进行测试。
offset比较小的时候：
| 代码如下 | 复制代码 |
|
select * from table limit 10,10 //多次运行，时间保持在0.0004-0.0005之间 Select * From table Where vid ＞=(Select vid From table Order By vid limit 10,1) limit 10 //多次运行，时间保持在0.0005-0.0006之间，主要是0.0006 offset大的时候： select * from table limit 10000,10 //多次运行，时间保持在0.0187左右 //多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优 |
|
下面我们来看个mysql千万级数据分页的方法，也是基于limit的
我们来做一个测试ipdatas表：
| 代码如下 | 复制代码 |
| CREATE TABLE `ipdatas` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `uid` INT(8) NOT NULL DEFAULT '0', `ipaddress` VARCHAR(50) NOT NULL, `source` VARCHAR(255) DEFAULT NULL, `track` VARCHAR(255) DEFAULT NULL, `entrance` VARCHAR(255) DEFAULT NULL, `createdtime` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00', `createddate` DATE NOT NULL DEFAULT '0000-00-00', PRIMARY KEY (`id`), KEY `uid` (`uid`) ) ENGINE=MYISAM AUTO_INCREMENT=67086110 DEFAULT CHARSET=utf8; |
|
这是我们做的广告联盟的推广ip数据记录表，由于我也不是mysql的DBA所以这里咱们仅仅是测试
因为原来里面有大概7015291条数据
这里我们通过jdbc的batch插入6000万条数据到此表当中“JDBC插入6000W条数据用时:9999297ms”；
大概用了两个多小时,这里面我用的是batch大小大概在1w多每次提交,还有一点是每次提交的数据都很小，而且这里用的myisam数据表，因为我需要知道mysql数据库的大小以及索引数据的大小结果是
ipdatas.MYD 3.99 GB (4,288,979,008 字节)
ipdatas.MYI 1.28 GB (1,377,600,512 字节)
这里面我要说的是如果真的是大数据如果时间需要索引还是最好改成数字字段,索引的大小和查询速度都比时间字段可观。
步入正题:
1.全表搜索
返回结构是67015297条数据
| 代码如下 | 复制代码 |
| SELECT COUNT(id) FROM ipdatas; SELECT COUNT(uid) FROM ipdatas; SELECT COUNT(*) FROM ipdatas; |
|
首先这两个全表数据查询速度很快,mysql中包含数据字典应该保留了数据库中的最大条数
查询索引条件
| 代码如下 | 复制代码 |
| SELECT COUNT(*) FROM ipdatas WHERE uid=1; 返回结果时间:2分31秒594 SELECT COUNT(id) FROM ipdatas WHERE uid=1; 返回结果时间:1分29秒609 SELECT COUNT(uid) FROM ipdatas WHERE uid=1; 返回结果时间:2分41秒813 |
|
第二次查询都比较快因为mysql中是有缓存区的所以增大缓存区的大小可以解决很多查询的优化，真可谓缓存无处不在啊在程序开发中也是层层都是缓存
查询数据
| 代码如下 | 复制代码 |
|
第一条开始查询 第500万条开始查询 第5000万条开始查询 |
|
第三条和第二条结果一样只是排序的方式不同但是用时却相差不少，看来这点还是不如很多的商业数据库,像oracle和sqlserver等都是中间不成两边还是没问题，看来mysql是开始行越向后越慢，这里看来可以不排序的就不要排序了性能差距巨大,相差了20多倍
查询数据返回ID列表
| 代码如下 | 复制代码 |
|
第一条开始查 第500万条开始查询 第6000万条记录开始查询 select id from ipdatas limit 10000002,10; 29.032s select * from ipdatas limit 10000002,10; 27.328s select id from ipdatas order by id asc limit 10000002,10; 29.438s
|
|
至于SELECT * ipdatas order by id asc 就不测试了 大概都在十几分钟左右
可见通过SELECT id 不带排序的情况下差距不太大,加了排序差距巨大
下面看看这条语句
| 代码如下 | 复制代码 |
| SELECT * FROM ipdatas WHERE id IN (10000,100000,500000,1000000,5000000,10000000,2000000,30000000,40000000,50000000,60000000,67015297); 耗时0.094ms |
|
可见in在id上面的查询可以忽略不计毕竟是6000多万条记录，所以为什么很多lucene或solr搜索都返回id进行数据库重新获得数据就是因为这个,当然lucene/solr+mysql是一个不错的解决办法这个非常适合前端搜索技术,比如前端的分页搜索通过这个可以得到非常好的性能.还可以支持很好的分组搜索结果集,然后通过id获得数据记录的真实数据来显示效果真的不错,别说是千万级别就是上亿也没有问题,真是易做图推荐啊.
总结了，最关键的一句是
网上的改法可以参考一下，暂时解决问题
| 代码如下 | 复制代码 |
| SELECT sql_no_cache *FROM table WHERE id>=(SELECTsql_no_cache id FROM table where conditon ORDER BY id DESC LIMIT 126380,1) limit 20; | |
很多问题大家可根据自身情况来分析优化mysql查询语句。
补充：数据库,mysql教程
