mysql千万级测试1亿数据的分页分析测试
本文为本人最近利用几个小时才分析总结出的原创文章,希望大家转载,但是要注明出处
http://blog.sina.com.cn/s/blog_438308750100im0e.html
有什么问题可以互相讨论:yubaojian0616@163.com 于堡舰
上一篇文章我们测试一些order by查询和分页查询的一些基准性能,现在我们来分析一下条件索引查询的结果集的测试
现在我们继续进行一个测试相同的表结构插入1亿条数据这次用到的是Innodb表引擎,表名有些变化,这里为甚要新建一个表的很重要元素是原来的那张表是每个uid=1来做的索引,这次uid是1...10不等的数每种1千万条记录
CREATE TABLE `ipdata` (
`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=InnoDB AUTO_INCREMENT=100004857 DEFAULT CHARSET=utf8
我开启了Innodb的线程数为128,因为innodb是行级别锁定,并发处理能力很强我开启100线程每个线程大小为100万记录插入时间如下
JDBC插入100w条数据此线程用时:9300984ms
JDBC插入100w条数据此线程用时:9381203ms
JDBC插入100w条数据此线程用时:9412343ms
JDBC插入100w条数据此线程用时:9442046ms
JDBC插入100w条数据此线程用时:9449828ms
JDBC插入100w条数据此线程用时:9484703ms
JDBC插入100w条数据此线程用时:9528093ms
JDBC插入100w条数据此线程用时:9533359ms
JDBC插入100w条数据此线程用时:9534296ms
JDBC插入100w条数据此线程用时:9539718ms
JDBC插入100w条数据此线程用时:9541750ms
JDBC插入100w条数据此线程用时:9636406ms
JDBC插入100w条数据此线程用时:9695093ms
JDBC插入100w条数据此线程用时:9806890ms
JDBC插入100w条数据此线程用时:9895500ms
JDBC插入100w条数据此线程用时:9989750ms
JDBC插入100w条数据此线程用时:10012312ms
JDBC插入100w条数据此线程用时:10037250ms
JDBC插入100w条数据此线程用时:10092796ms
JDBC插入100w条数据此线程用时:11993187ms
JDBC插入100w条数据此线程用时:12033203ms
JDBC插入100w条数据此线程用时:12068453ms
JDBC插入100w条数据此线程用时:12133625ms
JDBC插入100w条数据此线程用时:12212953ms
JDBC插入100w条数据此线程用时:12253421ms
JDBC插入100w条数据此线程用时:12284968ms
JDBC插入100w条数据此线程用时:12296421ms
JDBC插入100w条数据此线程用时:12366828ms
JDBC插入100w条数据此线程用时:12388093ms
JDBC插入100w条数据此线程用时:12389656ms
JDBC插入100w条数据此线程用时:12396625ms
JDBC插入100w条数据此线程用时:12417921ms
JDBC插入100w条数据此线程用时:12431000ms
JDBC插入100w条数据此线程用时:12432875ms
JDBC插入100w条数据此线程用时:12434703ms
JDBC插入100w条数据此线程用时:12455218ms
JDBC插入100w条数据此线程用时:12457109ms
JDBC插入100w条数据此线程用时:12484218ms
JDBC插入100w条数据此线程用时:12518375ms
JDBC插入100w条数据此线程用时:12519015ms
JDBC插入100w条数据此线程用时:12521109ms
JDBC插入100w条数据此线程用时:12521515ms
JDBC插入100w条数据此线程用时:12537343ms
JDBC插入100w条数据此线程用时:12539421ms
JDBC插入100w条数据此线程用时:12544250ms
JDBC插入100w条数据此线程用时:12559234ms
JDBC插入100w条数据此线程用时:12567484ms
JDBC插入100w条数据此线程用时:12574109ms
JDBC插入100w条数据此线程用时:12579156ms
JDBC插入100w条数据此线程用时:12638046ms
JDBC插入100w条数据此线程用时:12693047ms
JDBC插入100w条数据此线程用时:12722906ms
JDBC插入100w条数据此线程用时:12728781ms
JDBC插入100w条数据此线程用时:12732546ms
JDBC插入100w条数据此线程用时:12748265ms
JDBC插入100w条数据此线程用时:12757421ms
JDBC插入100w条数据此线程用时:12761375ms
JDBC插入100w条数据此线程用时:12765312ms
JDBC插入100w条数据此线程用时:12788359ms
JDBC插入100w条数据此线程用时:12802765ms
JDBC插入100w条数据此线程用时:12810484ms
JDBC插入100w条数据此线程用时:12811062ms
JDBC插入100w条数据此线程用时:12811796ms
JDBC插入100w条数据此线程用时:12812843ms
JDBC插入100w条数据此线程用时:12829671ms
JDBC插入100w条数据此线程用时:12830296ms
JDBC插入100w条数据此线程用时:12840000ms
JDBC插入100w条数据此线程用时:12840890ms
JDBC插入100w条数据此线程用时:12850312ms
JDBC插入100w条数据此线程用时:12856671ms
JDBC插入100w条数据此线程用时:12858609ms
JDBC插入100w条数据此线程用时:12860125ms
JDBC插入100w条数据此线程用时:12861750ms
JDBC插入100w条数据此线程用时:12864125ms
JDBC插入100w条数据此线程用时:12875609ms
JDBC插入100w条数据此线程用时:12875781ms
JDBC插入100w条数据此线程用时:12900859ms
JDBC插入100w条数据此线程用时:12906812ms
JDBC插入100w条数据此线程用时:12909656ms
JDBC插入100w条数据此线程用时:12913375ms
JDBC插入100w条数据此线程用时:12915609ms
JDBC插入100w条数据此线程用时:12917562ms
JDBC插入100w条数据此线程用时:12918000ms
JDBC插入100w条数据此线程用时:12919468ms
JDBC插入100w条数据此线程用时:12922093ms
JDBC插入100w条数据此线程用时:12922843ms
JDBC插入100w条数据此线程用时:12924375ms
JDBC插入100w条数据此线程用时:12925734ms
JDBC插入100w条数据此线程用时:12925781ms
JDBC插入100w条数据此线程用时:12931140ms
JDBC插入100w条数据此线程用时:12934562ms
JDBC插入100w条数据此线程用时:12934828ms
JDBC插入100w条数据此线程用时:12935281ms
JDBC插入100w条数据此线程用时:12936953ms
JDBC插入100w条数据此线程用时:12937218ms
JDBC插入100w条数据此线程用时:12937406ms
JDBC插入100w条数据此线程用时:12937765ms
JDBC插入100w条数据此线程用时:12939125ms
JDBC插入100w条数据此线程用时:12940281ms
JDBC插入100w条数据此线程用时:12941828ms
大概一共用了2个多小时内容为1亿条数据mysql的innodb中文件大小为 11.7 GB (12,660,506,624 字节);
首先来看看in查询
SELECT * FROM ipdata WHERE id IN(112358,201023,100020,100001,10000,100000,1000000,10000000,100000000); 141ms
SELECT * FROM ipdata WHERE id IN(12345,123456,1234567,12345678,987654,789654,1236985,852963,9745621,78965412); 141ms
看来in的查询还算理想,
然后我们进行分页必要查询不排序
SELECT id FROM ipdata WHERE uid=1 LIMIT 1,10; 31ms;
SELECT id FROM ipdata WHERE uid=1 LIMIT 10,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 LIMIT 100,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 LIMIT 1000,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 LIMIT 10000,10; 47ms;
SELECT id FROM ipdata WHERE uid=1 LIMIT 100000,10; 235ms;
SELECT id FROM ipdata WHERE uid=1 LIMIT 1000000,10; 1.438s;
SELECT id FROM ipdata WHERE uid=1 LIMIT 5000000,10; 5.422s;
SELECT id FROM ipdata WHERE uid=1 LIMIT 10000000,10; 9.562s; 无返回结果
SELECT id FROM ipdata WHERE uid=1 LIMIT 9999990,10; 10.953s;
符合上一篇的结论mysql越向后越慢,但是整体来说是可以接受的,毕竟分页到最后一页虽然用到了10秒钟,但是后台人员不可能到最后去看,第二呢,10秒后台人员也算可以接受级别;
分页排序查询
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 10,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 100,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1000,10; 0ms;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 10000,10; 47ms;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 100000,10; 266ms;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1000000,10; 1.594s;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 5000000,10; 5.625s;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id DESC LIMIT 5000000,10; 11.235s;
SELECT id FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 10000000,10; 11.562s 无返回结果
SELECT id FROM ipdata WHERE uid=1 ORDER BY ID ASC LIMIT 9999990,10; 11.719s;
SELECT id FROM ipdata WHERE uid=1 ORDER BY ID DESC LIMIT 9999990,10; 18.719s;
结论是如果单查找id,order by的时间比较可观,但是可见正序和倒序时间不同.
返回全部结果查询"*"
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1,10; 109ms;
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 10,10; 0ms;
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 100,10; 16ms;
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1000,10; 63ms;
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 10000,10; 356ms;
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 100000,10; 2.969s;
SELECT * FROM ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1000000,10; 30.766s;
select id,uid,ipaddress,source,track,entrance,createdtime,createddate from ipdata WHERE uid=1 ORDER BY id ASC LIMIT 1000000,10; 29.953s;
...下面的就不测试了,已经难以接受了
结论SELECT id 要比SELECT *快了不少至少在大的结果面前;
结果count测试
SELECT COUNT(*) FROM ipdata WHERE uid=1; 12.281s;
SELECT COUNT(*) FROM ipdata WHERE uid=2; 12.250s;
....
SELECT COUNT(*) FROM ipdata WHERE uid=10; 11.453s;
count级别大概是10多秒左右返回都是1000万;
Count(id)测试
SELECT COUNT(id) FROM ipdata WHERE uid=1; 10.281s;
SELECT COUNT(id) FROM ipdata WHERE uid=2; 10.531s;
....
SELECT COUNT(id) FROM ipdata WHERE uid=10; 12.531s;
Count(id)这里我不知道是机器原因可能测试不是十分准确,总之相差不大,不知道是否mysql默认通过唯一主键来count,如果*和id差不多都方便我还是推荐id,呵呵
这样我们可以通过SELECT id 来得到id列表,然后通过in来得到相应的记录,可见是可行的;还有在这次测试中我们通过uid这个属性来过滤掉了90%的结果集,如果根据95%过滤理想化可能还有点欠缺,但是根据80%过滤原则就不同了,至少这个索引还是理想的,过滤掉的内容看来mysql就可以算到千万级别的用时了。其实这里面的时间不代表真实时间,毕竟机器也是我们办公室一台pc电脑,数据也比较小,这里我只是有时间来测试一下千万条乃至上亿条数据的处理能力,到服务器上应该要比这个快很多,毕竟磁盘io差距大,而且cpu也有差距,
总结
1.mysql千万级别数据肯定是没问题的,毕竟现在的流向web2.0网站大部分是mysql的
2.合理分表也是必须的,主要涉及横向分表与纵向分表,如把大小字段分开,或者每100万条记录在一张表中等等,像上面的这个表可以考虑通过uid的范围分表,或者通过只建立索引表,去掉相对大的字段来处理.
3.count()时间比较长,但是本身是可以缓存在数据库中或者缓存在程序中的,因为我们当时使用在后台所以第一页比较慢但是后面比较理想
4.SELECT id 相对SELECT * 差距还是比较大的,可以通过上面的方法来使用SELECT id + SELECT * ... IN 查询来提高性能
5.必要的索引是必须的,还是要尽量返回5%-20%的结果级别其中小于5%最理想;
6.mysql分页的前面几页速度很快,越向后性能越差,可以考虑只带上一页,下一页不带页面跳转的方法,呵呵这个比较垃圾但是也算是个方案,只要在前后多查一条就能解决了.比如100,10 你就差99,12呵呵,这样看看前后是否有结果.
7.前台还是要通过其他手段来处理,比如lucene/Solr+mysql结合返回翻页结果集,或者上面的分表
8. 1亿的数据还在我们这里大家可以充分考虑搜索条件 我帮大家测试哈哈。
接下来我将要测试一些关于1亿+的用户数据表的解决方案,及大数据的搜索方案通过lucene/solr+mysql
mysql千万级测试1亿数据的分页分析测试的更多相关文章
- mysql千万级数据库插入速度和读取速度的调整记录
一般情况下mysql上百万数据读取和插入更新是没什么问题了,但到了上千万级就会出现很慢,下面我们来看mysql千万级数据库插入速度和读取速度的调整记录吧. 1)提高数据库插入性能中心思想:尽量将数据一 ...
- Mysql千万级大表优化
Mysql的单张表的最大数据存储量尚没有定论,一般情况下mysql单表记录超过千万以后性能会变得很差.因此,总结一些相关的Mysql千万级大表的优化策略. 1.优化sql以及索引 1.1优化sql 1 ...
- MySQL 百万级分页优化(Mysql千万级快速分页)(转)
http://www.jb51.net/article/31868.htm 以下分享一点我的经验 一般刚开始学SQL的时候,会这样写 复制代码 代码如下: SELECT * FROM table OR ...
- MySQL 百万级分页优化(Mysql千万级快速分页)
以下分享一点我的经验 一般刚开始学SQL的时候,会这样写 : SELECT * FROM table ORDER BY id LIMIT 1000, 10; 但在数据达到百万级的时候,这样写会慢死 : ...
- 如何优化MySQL千万级大表
很好的一篇博客,转载 如何优化MySQL千万级大表 原文链接::https://blog.csdn.net/yangjianrong1985/article/details/102675334 千万级 ...
- 如何优化Mysql千万级快速分页,limit优化快速分页,MySQL处理千万级数据查询的优化方案
如何优化Mysql千万级快速分页,limit优化快速分页,MySQL处理千万级数据查询的优化方案
- MySQL千万级大表优化解决方案
MySQL千万级大表优化解决方案 非原创,纯属记录一下. 背景 无意间看到了这篇文章,作者写的很棒,于是乎,本人自私一把,把干货保存下来.:-) 问题概述 使用阿里云rds for MySQL数据库( ...
- mysql千万级表关联优化
MYSQL一次千万级连表查询优化(一) 概述: 交代一下背景,这算是一次项目经验吧,属于公司一个已上线平台的功能,这算是离职人员挖下的坑,随着数据越来越多,原本的SQL查询变得越来越慢,用户体验特别差 ...
- mysql千万级数据表,创建表及字段扩展的几条建议
一:概述 当我们设计一个系统时,需要考虑到系统的运行一段时间后,表里数据量大约有多少,如果在初期,就能估算到某几张表数据量非常庞大时(比如聊天消息表),就要把表创建好,这篇文章从创建表,增加数据,以及 ...
随机推荐
- Web安全--使用Salt + Hash将密码加密后再存储进数据库
转载原地址 http://www.bozhiyue.com/mianshiti/_net/2016/0728/314239.html (一) 为什么要用哈希函数来加密密码 如果你需要保存密码(比如网站 ...
- HDU 1150 Machine Schedule (二分图最小点覆盖)
题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=1150 有两个机器a和b,分别有n个模式和m个模式.下面有k个任务,每个任务需要a的一个模式或者b的一个 ...
- Running Solr with Maven
Solr is an open source search server which is built by using the indexing and search capabilities of ...
- [转]sql server 数据库日期格式化函数
转至:http://www.cnblogs.com/hantianwei/archive/2009/12/03/1616148.html 0 或 100 (*) 默认值 mon ...
- [Windows驱动开发](一)序言
笔者学习驱动编程是从两本书入门的.它们分别是<寒江独钓——内核安全编程>和<Windows驱动开发技术详解>.两本书分别从不同的角度介绍了驱动程序的制作方法. 在我理解,驱动程 ...
- MongoDB 快速入门--初级
数据库的操作一般来说都是CRUD,这其中最难的就是查询,所有所我们先来了解MongoDB中的 插入(insert) 说到插入,我们就必须得说说如何创建数据库,如何创建集合,然后才是如何创建文档. 在这 ...
- HTML第一天学习笔记
- C#fixed关键字
fixed 语句禁止垃圾回收器重定位可移动的变量. fixed 语句只在 不安全的上下文中是允许的. Fixed 还可用于创建 固定大小缓冲区. fixed 语句设置指向托管变量的指针,并在执行该语句 ...
- PI-安装SoapUI on Windows
SoapUI是测试webservice连通性的工具,请见博文:http://www.dekevin.com/?p=1807 当你下载好了SOAPUI的安装程序之后,就可以进行程序的安装了,怎么来进行S ...
- Android通过http协议POST传输方式
Android通过http协议POST传输方式如下: 方式一:HttpPost(import org.apache.http.client.methods.HttpPost) 代码如下: privat ...