免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP，暢享免費(fèi)電子書等14項(xiàng)超值服

開通VIP

首頁(yè)

好書

留言交流

下載APP

聯(lián)系客服
mysql數(shù)據(jù)庫(kù)千萬(wàn)級(jí)別數(shù)據(jù)的查詢優(yōu)化和分頁(yè)測(cè)試

mysql數(shù)據(jù)庫(kù)千萬(wàn)級(jí)別數(shù)據(jù)的查詢優(yōu)化和分頁(yè)測(cè)試

發(fā)表于2 年 前(2012-07-02 10:52)   閱讀（1106） | 評(píng)論（0） 4人收藏此文章, 我要收藏
贊1

我原來(lái)的公司是一家網(wǎng)絡(luò)游戲公司,其中網(wǎng)站交易與游戲數(shù)據(jù)庫(kù)結(jié)合通過(guò)ws實(shí)現(xiàn)的,但是交易記錄存放在網(wǎng)站上,級(jí)別是千萬(wàn)級(jí)別的數(shù)據(jù)庫(kù)是mysql數(shù)據(jù)庫(kù).
 
  可能有人會(huì)問(wèn)mysql是否支持千萬(wàn)級(jí)數(shù)據(jù)庫(kù),還有既然已經(jīng)到了這個(gè)數(shù)據(jù)量公司肯定不差,為什么要用mysql而不用oracle這里我做一下解答
  1. mysql絕對(duì)支持千萬(wàn)級(jí)數(shù)據(jù)庫(kù)是可以肯定的，
  2. 為什么選擇擇mysql呢？
 1> 第一也是最主要的一條是mysql他能做到。
 2> 在第一點(diǎn)前提下以下的就不是太重要了,mysql相對(duì)操作簡(jiǎn)單,測(cè)試容易,配置優(yōu)化也相對(duì)容易很多
 3> 我們這里的數(shù)據(jù)僅僅是為了記錄交易保證交易是被記錄的,對(duì)于查詢的還是相對(duì)少只有管理后臺(tái)操作中需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行查詢
 4> 數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單,而且每條記錄都非常小,因?yàn)椴樵兯俣炔还芎陀涗洍l數(shù)有關(guān)和數(shù)據(jù)文件大小也有直接關(guān)系.
 5> 我們采用的是大小表的解決辦法,每天大概需要插入數(shù)據(jù)庫(kù)好幾百萬(wàn)條,這里可能還是有人懷疑,其實(shí)沒(méi)問(wèn)題,如果批量插入我測(cè)試的在普通的pc機(jī)子上帶該一個(gè) 線程并發(fā)我插入的是6千萬(wàn)條記錄大概需要“JDBC插入6000W條數(shù)據(jù)用時(shí):9999297ms”,小表保存最近插入的內(nèi)容,把幾天前的保存到大表中, 這里我說(shuō)的就是大表大概6-7千萬(wàn)條數(shù)據(jù);
 
  帶著這些疑問(wèn)和求知欲望咱們來(lái)做一個(gè)測(cè)試，因?yàn)樵谀莻€(gè)時(shí)候我也不是dba不知道人家是怎么搞的能夠做成這么大的數(shù)據(jù)量,我們平時(shí)葉總探討一些相關(guān)的內(nèi)容

  1.mysql的數(shù)據(jù)查詢,大小字段要分開,這個(gè)還是有必要的,除非一點(diǎn)就是你查詢的都是索引內(nèi)容而不是表內(nèi)容,比如只查詢id等等
  2.查詢速度和索引有很大關(guān)系也就是索引的大小直接影響你的查詢效果,但是查詢條件一定要建立索引,這點(diǎn)上注意的是索引字段不能太多，太多索引文件就會(huì)很大那樣搜索只能變慢,
  3.查詢指定的記錄最好通過(guò)Id進(jìn)行in查詢來(lái)獲得真實(shí)的數(shù)據(jù).其實(shí)不是最好而是必須，也就是你應(yīng)該先查詢出復(fù)合的ID列表,通過(guò)in查詢來(lái)獲得數(shù)據(jù)

  我們來(lái)做一個(gè)測(cè)試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;
  這是我們做的廣告聯(lián)盟的推廣ip數(shù)據(jù)記錄表，由于我也不是mysql的DBA所以這里咱們僅僅是測(cè)試
  因?yàn)樵瓉?lái)里面有大概7015291條數(shù)據(jù)

  這里我們通過(guò)jdbc的batch插入6000萬(wàn)條數(shù)據(jù)到此表當(dāng)中“JDBC插入6000W條數(shù)據(jù)用時(shí):9999297ms”；
  大概用了兩個(gè)多小時(shí),這里面我用的是batch大小大概在1w多每次提交,還有一點(diǎn)是每次提交的數(shù)據(jù)都很小，而且這里用的myisam數(shù)據(jù)表，因?yàn)槲倚枰續(xù)ysql數(shù)據(jù)庫(kù)的大小以及索引數(shù)據(jù)的大小結(jié)果是
  ipdatas.MYD 3.99 GB (4,288,979,008 字節(jié))
  ipdatas.MYI 1.28 GB (1,377,600,512 字節(jié))
  這里面我要說(shuō)的是如果真的是大數(shù)據(jù)如果時(shí)間需要索引還是最好改成數(shù)字字段,索引的大小和查詢速度都比時(shí)間字段可觀。

  步入正題:
  1.全表搜索
 返回結(jié)構(gòu)是67015297條數(shù)據(jù)
   SELECT COUNT(id) FROM ipdatas;
   SELECT COUNT(uid) FROM ipdatas;
   SELECT COUNT(*) FROM ipdatas;
   首先這兩個(gè)全表數(shù)據(jù)查詢速度很快,mysql中包含數(shù)據(jù)字典應(yīng)該保留了數(shù)據(jù)庫(kù)中的最大條數(shù)
 查詢索引條件
   SELECT COUNT(*) FROM ipdatas WHERE uid=1;   返回結(jié)果時(shí)間:2分31秒594
   SELECT COUNT(id) FROM ipdatas WHERE uid=1;  返回結(jié)果時(shí)間:1分29秒609
   SELECT COUNT(uid) FROM ipdatas WHERE uid=1; 返回結(jié)果時(shí)間:2分41秒813
   第二次查詢都比較快因?yàn)閙ysql中是有緩存區(qū)的所以增大緩存區(qū)的大小可以解決很多查詢的優(yōu)化，真可謂緩存無(wú)處不在啊在程序開發(fā)中也是層層都是緩存
 查詢數(shù)據(jù)
   第一條開始查詢
   SELECT * FROM ipdatas ORDER BY id DESC LIMIT 1,10 ; 31毫秒
   SELECT * FROM ipdatas LIMIT 1,10 ; 15ms
  
   第10000條開始查詢
   SELECT * FROM ipdatas ORDER BY id ASC LIMIT 10000,10 ; 266毫秒
   SELECT * FROM ipdatas LIMIT 10000,10 ; 16毫秒

   第500萬(wàn)條開始查詢
   SELECT * FROM ipdatas LIMIT 5000000,10 ;11.312秒
   SELECT * FROM ipdatas ORDER BY id ASC LIMIT 5000000,10 ; 221.985秒
   這兩條返回結(jié)果完全一樣,也就是mysql默認(rèn)機(jī)制就是id正序然而時(shí)間卻大相徑庭

   第5000萬(wàn)條開始查詢
   SELECT * FROM ipdatas LIMIT 60000000,10 ;66.563秒 (對(duì)比下面的測(cè)試)
   SELECT * FROM ipdatas ORDER BY id ASC LIMIT 50000000,10; 1060.000秒
   SELECT * FROM ipdatas ORDER BY id DESC LIMIT 17015307,10; 434.937秒
   第三條和第二條結(jié)果一樣只是排序的方式不同但是用時(shí)卻相差不少，看來(lái)這點(diǎn)還是不如很多的商業(yè)數(shù)據(jù)庫(kù),像oracle和sqlserver等都是中間不成兩邊還是沒(méi)問(wèn)題，看來(lái)mysql是開始行越向后越慢，這里看來(lái)可以不排序的就不要排序了性能差距巨大,相差了20多倍

 查詢數(shù)據(jù)返回ID列表
   第一條開始查
   select id from ipdatas order by id asc limit 1,10; 31ms
   SELECT id FROM ipdatas LIMIT 1,10 ; 0ms
  
   第10000條開始
   SELECT id FROM ipdatas ORDER BY id ASC LIMIT 10000,10; 68ms
   select id from ipdatas limit 10000,10;0ms

   第500萬(wàn)條開始查詢
   SELECT id FROM ipdatas LIMIT 5000000,10; 1.750s
   SELECT id FROM ipdatas ORDER BY id ASC LIMIT 5000000,10;14.328s

   第6000萬(wàn)條記錄開始查詢
   SELECT id FROM ipdatas LIMIT 60000000,10; 116.406s
   SELECT id FROM ipdatas ORDER BY id ASC LIMIT 60000000,10; 136.391s

   select id from ipdatas limit 10000002,10; 29.032s
   select id from ipdatas limit 20000002,10; 24.594s
   select id from ipdatas limit 30000002,10; 24.812s 
   select id from ipdatas limit 40000002,10; 28.750s  84.719s
   select id from ipdatas limit 50000002,10; 30.797s  108.042s
   select id from ipdatas limit 60000002,10; 133.012s  122.328s

   select * from ipdatas limit 10000002,10; 27.328s
   select * from ipdatas limit 20000002,10; 15.188s
   select * from ipdatas limit 30000002,10; 45.218s
   select * from ipdatas limit 40000002,10; 49.250s   50.531s
   select * from ipdatas limit 50000002,10; 73.297s   56.781s
   select * from ipdatas limit 60000002,10; 67.891s   75.141s

   select id from ipdatas order by id asc limit 10000002,10; 29.438s
   select id from ipdatas order by id asc limit 20000002,10; 24.719s
   select id from ipdatas order by id asc limit 30000002,10; 25.969s
   select id from ipdatas order by id asc limit 40000002,10; 29.860d
   select id from ipdatas order by id asc limit 50000002,10; 32.844s
   select id from ipdatas order by id asc limit 60000002,10; 34.047s

   至于SELECT * ipdatas order by id asc 就不測(cè)試了 大概都在十幾分鐘左右
   可見通過(guò)SELECT id 不帶排序的情況下差距不太大,加了排序差距巨大
   下面看看這條語(yǔ)句
   SELECT * FROM ipdatas WHERE id IN (10000,100000,500000,1000000,5000000,10000000,2000000,30000000,40000000,50000000,60000000,67015297);
   耗時(shí)0.094ms
   可見in在id上面的查詢可以忽略不計(jì)畢竟是6000多萬(wàn)條記錄，所以為什么很多l(xiāng)ucene或solr搜索都返回id進(jìn)行數(shù)據(jù)庫(kù)重新獲得數(shù)據(jù)就是因?yàn)檫@ 個(gè),當(dāng)然lucene/solr+mysql是一個(gè)不錯(cuò)的解決辦法這個(gè)非常適合前端搜索技術(shù),比如前端的分頁(yè)搜索通過(guò)這個(gè)可以得到非常好的性能.還可以支 持很好的分組搜索結(jié)果集,然后通過(guò)id獲得數(shù)據(jù)記錄的真實(shí)數(shù)據(jù)來(lái)顯示效果真的不錯(cuò),別說(shuō)是千萬(wàn)級(jí)別就是上億也沒(méi)有問(wèn)題,真是吐血推薦啊.

 

上面的內(nèi)容還沒(méi)有進(jìn)行有條件的查詢僅僅是一些關(guān)于orderby和limit的測(cè)試,請(qǐng)關(guān)注我的下一篇文件對(duì)于條件查詢的1億數(shù)據(jù)檢索測(cè)試


mysql千萬(wàn)級(jí)測(cè)試1億數(shù)據(jù)的分頁(yè)分析測(cè)試

發(fā)表于2 年 前(2012-07-02 10:51)   閱讀（715） | 評(píng)論（1） 3人收藏此文章, 我要收藏
贊0

上一篇文章我們測(cè)試一些order by查詢和分頁(yè)查詢的一些基準(zhǔn)性能,現(xiàn)在我們來(lái)分析一下條件索引查詢的結(jié)果集的測(cè)試

 

現(xiàn)在我們繼續(xù)進(jìn)行一個(gè)測(cè)試相同的表結(jié)構(gòu)插入1億條數(shù)據(jù)這次用到的是Innodb表引擎,表名有些變化,這里為甚要新建一個(gè)表的很重要元素是原來(lái)的那張表是每個(gè)uid=1來(lái)做的索引,這次uid是1...10不等的數(shù)每種1千萬(wàn)條記錄
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的線程數(shù)為128,因?yàn)閕nnodb是行級(jí)別鎖定，并發(fā)處理能力很強(qiáng)我開啟100線程每個(gè)線程大小為100萬(wàn)記錄插入時(shí)間如下
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9300984ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9381203ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9412343ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9442046ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9449828ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9484703ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9528093ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9533359ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9534296ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9539718ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9541750ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9636406ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9695093ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9806890ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9895500ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):9989750ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):10012312ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):10037250ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):10092796ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):11993187ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12033203ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12068453ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12133625ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12212953ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12253421ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12284968ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12296421ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12366828ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12388093ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12389656ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12396625ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12417921ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12431000ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12432875ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12434703ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12455218ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12457109ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12484218ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12518375ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12519015ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12521109ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12521515ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12537343ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12539421ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12544250ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12559234ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12567484ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12574109ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12579156ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12638046ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12693047ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12722906ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12728781ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12732546ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12748265ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12757421ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12761375ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12765312ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12788359ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12802765ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12810484ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12811062ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12811796ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12812843ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12829671ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12830296ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12840000ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12840890ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12850312ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12856671ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12858609ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12860125ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12861750ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12864125ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12875609ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12875781ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12900859ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12906812ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12909656ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12913375ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12915609ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12917562ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12918000ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12919468ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12922093ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12922843ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12924375ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12925734ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12925781ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12931140ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12934562ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12934828ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12935281ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12936953ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12937218ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12937406ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12937765ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12939125ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12940281ms
JDBC插入100w條數(shù)據(jù)此線程用時(shí):12941828ms
大概一共用了2個(gè)多小時(shí)內(nèi)容為1億條數(shù)據(jù)mysql的innodb中文件大小為 11.7 GB (12,660,506,624 字節(jié));
首先來(lái)看看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
看來(lái)in的查詢還算理想,
然后我們進(jìn)行分頁(yè)必要查詢不排序
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; 無(wú)返回結(jié)果
SELECT id FROM ipdata WHERE uid=1 LIMIT 9999990,10; 10.953s;
符合上一篇的結(jié)論mysql越向后越慢,但是整體來(lái)說(shuō)是可以接受的,畢竟分頁(yè)到最后一頁(yè)雖然用到了10秒鐘,但是后臺(tái)人員不可能到最后去看,第二呢,10秒后臺(tái)人員也算可以接受級(jí)別;


分頁(yè)排序查詢
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 無(wú)返回結(jié)果
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;
結(jié)論是如果單查找id,order by的時(shí)間比較可觀,但是可見正序和倒序時(shí)間不同.

 

返回全部結(jié)果查詢"*"
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;
...下面的就不測(cè)試了,已經(jīng)難以接受了
結(jié)論SELECT id 要比SELECT *快了不少至少在大的結(jié)果面前;

 

結(jié)果count測(cè)試
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級(jí)別大概是10多秒左右返回都是1000萬(wàn);

Count(id)測(cè)試
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)這里我不知道是機(jī)器原因可能測(cè)試不是十分準(zhǔn)確,總之相差不大,不知道是否mysql默認(rèn)通過(guò)唯一主鍵來(lái)count,如果*和id差不多都方便我還是推薦id,呵呵


   這樣我們可以通過(guò)SELECT id 來(lái)得到id列表,然后通過(guò)in來(lái)得到相應(yīng)的記錄,可見是可行的;還有在這次測(cè)試中我們通過(guò)uid這個(gè)屬性來(lái)過(guò)濾掉了90%的結(jié)果集,如果根據(jù)95%過(guò)濾理 想化可能還有點(diǎn)欠缺,但是根據(jù)80%過(guò)濾原則就不同了,至少這個(gè)索引還是理想的，過(guò)濾掉的內(nèi)容看來(lái)mysql就可以算到千萬(wàn)級(jí)別的用時(shí)了。其實(shí)這里面的時(shí) 間不代表真實(shí)時(shí)間,畢竟機(jī)器也是我們辦公室一臺(tái)pc電腦,數(shù)據(jù)也比較小,這里我只是有時(shí)間來(lái)測(cè)試一下千萬(wàn)條乃至上億條數(shù)據(jù)的處理能力,到服務(wù)器上應(yīng)該要比 這個(gè)快很多,畢竟磁盤io差距大,而且cpu也有差距,
 
總結(jié)
 1.mysql千萬(wàn)級(jí)別數(shù)據(jù)肯定是沒(méi)問(wèn)題的,畢竟現(xiàn)在的流向web2.0網(wǎng)站大部分是mysql的
 2.合理分表也是必須的,主要涉及橫向分表與縱向分表,如把大小字段分開,或者每100萬(wàn)條記錄在一張表中等等,像上面的這個(gè)表可以考慮通過(guò)uid的范圍分表,或者通過(guò)只建立索引表,去掉相對(duì)大的字段來(lái)處理.
 3.count()時(shí)間比較長(zhǎng),但是本身是可以緩存在數(shù)據(jù)庫(kù)中或者緩存在程序中的,因?yàn)槲覀儺?dāng)時(shí)使用在后臺(tái)所以第一頁(yè)比較慢但是后面比較理想
 4.SELECT id 相對(duì)SELECT * 差距還是比較大的,可以通過(guò)上面的方法來(lái)使用SELECT id + SELECT * ... IN 查詢來(lái)提高性能
 5.必要的索引是必須的,還是要盡量返回5%-20%的結(jié)果級(jí)別其中小于5%最理想;
 6.mysql分頁(yè)的前面幾頁(yè)速度很快,越向后性能越差,可以考慮只帶上一頁(yè),下一頁(yè)不帶頁(yè)面跳轉(zhuǎn)的方法,呵呵這個(gè)比較垃圾但是也算是個(gè)方案,只要在前后多查一條就能解決了.比如100,10 你就差99,12呵呵，這樣看看前后是否有結(jié)果.
 7.前臺(tái)還是要通過(guò)其他手段來(lái)處理,比如lucene/Solr+mysql結(jié)合返回翻頁(yè)結(jié)果集,或者上面的分表
 8. 1億的數(shù)據(jù)還在我們這里大家可以充分考慮搜索條件 我?guī)痛蠹覝y(cè)試哈哈。

 

接下來(lái)我將要測(cè)試一些關(guān)于1億+的用戶數(shù)據(jù)表的解決方案,及大數(shù)據(jù)的搜索方案通過(guò)lucene/solr+mysql

本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊舉報(bào)。
打開APP，閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
原創(chuàng)?mysql數(shù)據(jù)庫(kù)千萬(wàn)級(jí)別數(shù)據(jù)的查詢優(yōu)化和分頁(yè)測(cè)試
如何通過(guò) Docker 部署 Logstash 同步 Mysql 數(shù)據(jù)庫(kù)數(shù)據(jù)到 ElasticSearch
ShardingJdbc分庫(kù)分表實(shí)戰(zhàn)案例解析（下）
 mysql刪除/更新數(shù)據(jù)時(shí) 報(bào)錯(cuò) Lock wait timeout exceeded; try restarting transaction 鎖超時(shí)
長(zhǎng)這么大這個(gè) MySQL bug 讓我大開眼界
史上最全的常用MySQL命令語(yǔ)句大全
更多類似文章 >>
生活服務(wù)
分享 收藏 導(dǎo)長(zhǎng)圖 關(guān)注 下載文章
綁定賬號(hào)成功
后續(xù)可登錄賬號(hào)暢享VIP特權(quán)！
如果VIP功能使用有故障，
可點(diǎn)擊這里聯(lián)系客服！

聯(lián)系客服