- 浏览: 914595 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (498)
- J2EE (52)
- 数据库 (17)
- java基础 (43)
- web技术 (19)
- 程序设计 (6)
- 操作系统 (18)
- IT资讯 (7)
- 我的IT生活 (12)
- 学习笔记 (9)
- Jquery (25)
- JavaScript (18)
- spring (40)
- Hibernate (12)
- Struts (10)
- YUI (2)
- Extjs (22)
- .net (0)
- Eclipse (10)
- 社会主义 (2)
- 服务器 (9)
- CSS (8)
- 网络安全 (16)
- 版本控制 (9)
- PHP (2)
- Oracle (42)
- SQL server (1)
- Mysql (11)
- 项目管理 (3)
- 开发工具使用 (10)
- SQL语句 (7)
- Perl (0)
- Shell (6)
- 漏洞 (4)
- ibatis (5)
- hacker (2)
- SQL注入 (6)
- Hacker工具 (2)
- 入侵和渗透 (7)
- 插件/组件 (2)
- 最爱开源 (5)
- 常用软件 (2)
- DOS (1)
- HTML (2)
- Android (9)
- CMS (1)
- portal (8)
- Linux (7)
- OSGI (1)
- Mina (5)
- maven (2)
- hadoop (7)
- twitter storm (2)
- sap hana (0)
- OAuth (0)
- RESTful (1)
- Nginx (4)
- flex (1)
- Dubbo (1)
- redis (1)
- springMVC (1)
- node.js (1)
- solr (2)
- Flume (1)
- MongoDB (2)
- ElasticSearch (1)
最新评论
-
M_drm:
请问要怎么设置浏览器才不报没权限呢?
用JS在页面调用本地可执行文件的方法(ACTIVEX) -
Alexniver:
官方文档。When importing data into I ...
mysql导入数据过慢 解决方法 -
camelwoo:
我记得 Criteria 可以做连接查询与子查询,也可以做分页 ...
Hibernate总结篇二 -
zhenglongfei:
楼主如果SubKeyName 这个节点不存在,怎么办??怎么用 ...
Java操作注册表 -
yxx676229549:
用log4j 2 了
logback
本文为本人最近利用几个小时才分析总结出的原创文章,希望大家转载,但是要注明出处
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
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命令行导出数据库
2013-11-25 16:22 865MySQL命令行导出数据库 ... -
MySQL分组后取前N条的解决方案,mysql子查询limit条数
2013-11-23 14:26 0Mysql当前版本不支持第一层子查询中使用in limit等几 ... -
mysql数据库千万级别数据的查询优化和分页测试
2013-11-23 14:14 1682原文地址:原创 mysql数 ... -
mysql导入数据过慢 解决方法
2013-11-23 14:13 3955mysql中用 mysql->use test; m ... -
MySQL和MSSQL下,text 、ntext、 image、blob的比较
2013-06-18 09:55 14551、MySQL存在text和blob: ... -
mysql性能的检查和调优方法
2013-05-16 18:58 864mysql性能的检查和调优方法 http://www.sudo ... -
MYSQL数据库命名及设计规范
2013-05-16 14:53 8481.设计原则 1) 标准化和规范化 数据的标准化有助于消除数 ... -
关于 MySQL connections 的一些知识
2013-05-15 22:53 879关于 MySQL connections 的一些知识 请看下面 ... -
Mysq一般优化
2013-05-15 22:51 841我们使用MySQL5.0.XX版本,数据库引擎是InnoDB。 ... -
定制ibator前的一些思考
2013-05-15 15:33 911定制ibator前的一些思考 http://mov-webh ... -
MySQL忘记root口令的解决方法
2012-09-12 13:05 1085http://raincoder.iteye.com/blog ...
相关推荐
### MySQL 百万级分页优化(Mysql千万级快速分页) #### 背景与挑战 在处理大规模数据集时,例如拥有数百万乃至数千万条记录的数据库表,传统的分页查询方法可能会遇到性能瓶颈。特别是使用`LIMIT`进行分页时,随着...
在实际开发中,我们经常会遇到 MySQL 数据库的性能问题,特别是在处理千万级数据时,分页查询的性能会变得非常慢。在这篇文章中,我们将探讨如何优化 MySQL 千万级快速分页,详细介绍解决方案。 问题描述 我们有一...
Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql测试数据。Mysql...
【MySQL千万级大表深度分页慢的原因及优化方法】 在MySQL中,处理千万级大表的深度分页查询时,通常会遇到性能问题。这是因为MySQL的查询优化器在面对大量数据的分页请求时,可能选择全表扫描而不是利用索引来提高...
mysql快速导入百万级千万级数据 mysql快速导入百万级千万级数据 mysql快速导入百万级千万级数据 mysql快速导入百万级千万级数据 mysql快速导入百万级千万级数据 mysql快速导入百万级千万级数据
本文将围绕“mysql百万级测试数据下载 300W条”这个主题,深入探讨如何处理和利用这样的大数据量进行测试。 首先,`test.sql`文件是一个MySQL数据库的SQL脚本文件,通常包含创建表结构、插入数据等操作。在这个场景...
### 千万级Mysql-MongoDB性能对比报告 #### 测试环境配置 - CPU: i5 3.30GHz - 内存: 8GB - 操作系统: Windows 7 #### 测试工具与语言 - **Python**作为测试语言 - **MySQL**版本: 5.1,连接工具为**PyMySQL** -...
在MySQL数据库中,分页是处理大量数据查询时不可或缺的一种技术。它允许用户按需加载数据,而不是一次性获取所有记录,从而提高了用户体验并降低了服务器负载。以下是对分页实现的详细说明: 一、基础概念 分页是将...
"MySQL 百万级数据测试"这个主题涉及到了在高容量数据环境下的数据库操作,尤其是如何高效地导入和管理大量数据。MySQL是一个广泛使用的开源关系型数据库管理系统,它以其性能、可靠性和易用性而受到青睐。 首先,...
在千万级数据测试中,这些脚本可能用于模拟实际业务场景,例如,创建课程表,插入大量课程记录,然后进行各种查询操作,以此来验证ShardingJDBC的分片策略和性能。 在SQL方面,以下是一些关键知识点: 1. **索引...
本次测试的重点是分析在千万级数据下数据库的查询速度,首先得插入数据,采用 java 程序批量插入 1000 万条数据,分别插入 SQL Server 2008 和 Mysql 5.5 中。批量插入的方法就在 insert values 之后不断添加(…,…....
缺点:有优化瓶颈,数据量过亿就玩完了。 方案二:升级数据库类型,换一种100%兼容mysql的数据库。优点:不影响现有业务,源程序不需要修改代码,你几乎不需要做任何操作就能提升数据库性能,缺点:多花钱 方案三...
1. **性能测试**:通过导入这30W条数据,可以测试MySQL在高并发读写、复杂查询等方面的表现。例如,查看索引的建立是否合理,是否能有效提高查询速度;检查数据库的内存配置是否满足大数据量操作的需求;评估查询...
后端开发中为了防止一次性加载太多数据导致内存、磁盘IO都开销过大,经常需要分页展示,这个时候就需要用到MySQL的LIMIT关键字。但你以为LIMIT分页就万事大吉了么,Too young,too simple啊,LIMIT在数据量大的时候极...
1.使用人员可以指定迁移数据库类型 如:(orcal,sqlServer,csv 迁移至mysql) 2.在迁移数据库时,可以只迁移指定字段. 3.开发多任务的平台,按权重去执行任务,如:权重为1,1,2,3,4 那么1,1的权重一起执行,执行完毕后2...
这个200万条数据的测试集是实践上述理论的好素材,可以帮助我们深入理解MySQL在大数据场景下的表现,优化数据库设计和SQL语句,提升系统整体性能。通过实际操作和测试,我们可以更好地掌握MySQL数据库的相关知识。
Node.js结合MySQL实现分页查询是一种常见的数据处理方式,在Web应用中尤为常见。分页可以有效提高页面的响应速度,并优化用户的浏览体验。本文主要介绍了在Node.js环境下,如何使用MySQL数据库实现分页功能。 首先...
总的来说,这个压缩包提供的数据集是一个学习和测试MySQL功能的好素材,涵盖了新闻和城市两大主题,涵盖了数据库设计、SQL查询、数据分析等多个方面。通过对这些数据的处理和分析,你可以深入理解数据库管理和数据...
在MySQL数据库管理中,分页查询是常见的操作,特别是在数据量庞大的情况下,为了提高用户体验,分页能够有效地加载和展示数据。高效的分页查询对于优化数据库性能至关重要。本篇文章将探讨如何在MySQL中实现高效的...
使用大数据处理工具NIFI,进行数据从Postgresql中导入到MySql中,实现数据的同步处理,处理的时候,是带有分页的,因为作者正在做相关的项目,而,用nifi同步数据好说,如何,进行数据的分页同步不好弄,这里,主要是,采用...