1.mysql的資料查詢,大小欄位要分開,這個還是有必要的,除非一點就是你查詢的都是索引內容而不是表內容,比如只查詢id等等
2.查詢速度和索引有很大關係也就是索引的大小直接影響你的查詢效果,但是查詢條件一定要建立索引,這點上注意的是索引字段不能太多，太多索引檔案就會很大那樣搜尋只能變慢
,3.查詢指定的記錄最好通過id進行in查詢來獲得真實的資料.其實不是最好而是必須，也就是你應該先查詢出復合的id列表,通過in查詢來獲得資料
我們做個測試
sql**
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
notnull
default
'0000-00-00',
primary
key (`id`),
key `uid` (`uid`)
) engine=myisam auto_increment=67086110 default charset=utf8;
裡面有七百萬資料。
1.全表搜尋
返回結構是67015297條資料
select count(id) from ipdatas;
select count(uid) from ipdatas;
select count(*) from ipdatas;
813第二次查詢都比較快因為mysql中是有快取區的所以增大快取區的大小可以解決很多查詢的優化，真可謂快取無處不在啊在程式開發中也是層層都是快取 第一條開始查詢
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萬條開始查詢
select * from ipdatas limit 5000000,10 ;11.312
秒select * from ipdatas order by id asc limit 5000000,10 ; 221.985
秒這兩條返回結果完全一樣,也就是mysql預設機制就是id正序然而時間卻大相徑庭
第5000萬條開始查詢
select * from ipdatas limit 60000000,10 ;66.563
秒 (對比下面的測試
)select * from ipdatas order by id asc limit 50000000,10; 1060.000秒
select * from ipdatas order by id desc limit 17015307,10; 434.937
秒第三條和第二條結果一樣只是排序的方式不同但是用時卻相差不少，看來這點還是不如很多的商業資料庫,像oracle和sqlserver等都是中間不成兩邊還是沒問題，看來mysql是開始行越向後越慢，這裡看來可以不排序的就不要排序了效能差距巨大,相差了20多倍
查詢資料返回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萬條開始查詢
select id from ipdatas limit 5000000,10; 1.750s
select id from ipdatas order by id asc limit 5000000,10;14.328s
第6000萬條記錄開始查詢
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
就不測試了
大概都在十幾分鐘左右
可見通過
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獲得資料記錄的真實資料來顯示效果真的不錯
MySQL處理千萬級資料查詢 分頁
mysql資料庫優化處理實現千萬級快速分頁分析，來看下吧。資料表 collect id,title info vtype 就這4個字段，其中 title 用定長，info 用text,id 是逐漸，vtype是tinyint，vtype是索引。這是乙個基本的新聞系統的簡單模型。現在往裡面填充資料，填...
MySQL處理千萬級資料查詢 分頁
mysql資料庫優化處理實現千萬級快速分頁分析，來看下吧。資料表 collect id,title info vtype 就這4個字段，其中 title 用定長，info 用text,id 是逐漸，vtype是tinyint，vtype是索引。這是乙個基本的新聞系統的簡單模型。現在往裡面填充資料，填...
MySQL處理千萬級資料查詢 分頁
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！mysql資料庫優化處理實現千萬級快速分頁分析，來看下吧。資料表 collect id,title info vtype 就這4個字段，其中 title 用定長，info 用text,id 是逐漸，vtype是tinyint，vtype是索引。這是...