mysql 如何更好的給一個千萬級數據量的表增

例子：

創新互聯建站服務項目包括達日網站建設、達日網站制作、達日網頁制作以及達日網絡營銷策劃等。多年來，我們專注于互聯網行業，利用自身積累的技術優勢、行業經驗、深度合作伙伴關系等，向廣大中小型企業、政府機構等提供互聯網行業的解決方案，達日網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到達日省份的部分城市，未來相信會繼續擴大服務區域并繼續獲得客戶的支持與信任！

數據表 collect ( id, title ,info ,vtype) 就這4個字段，其中 title 用定長，info 用text, id 是逐漸，vtype是tinyint，vtype是索引。這是一個基本的新聞系統的簡單模型。現在往里面填充數據，填充10萬篇新聞。

最后collect 為 10萬條記錄，數據庫表占用硬盤1.6G。OK ,看下面這條sql語句：

select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的

select id,title from collect limit 90000,10; 從9萬條開始分頁，結果？

8-9秒完成，my god 哪出問題了？？？？其實要優化這條數據，網上找得到答案。看下面一條語句:

select id from collect order by id limit 90000,10; 很快，0.04秒就OK。為什么？因為用了id主鍵做索引當然快。網上的改法是：

select id,title from collect where id=(select id from collect order by id limit 90000,1) limit 10;

這就是用了id做索引的結果。可是問題復雜那么一點點，就完了。看下面的語句

select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！

到了這里我相信很多人會和我一樣，有崩潰感覺！vtype 做了索引了啊？怎么會慢呢？vtype做了索引是不錯，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，從9萬開始，那就是0.05*90=4.5秒的速度了。和測試結果8-9秒到了一個數量級。從這里開始有人提出了分表的思路，這個和discuz 論壇是一樣的思路。思路如下：

建一個索引表： t (id,title,vtype) 并設置成定長，然后做分頁，分頁出結果再到 collect 里面去找info 。 是否可行呢？實驗下就知道了。

10萬條記錄到 t(id,title,vtype) 里，數據表大小20M左右。用

select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。為什么會這樣呢？我猜想是因為collect 數據太多，所以分頁要跑很長的路。limit 完全和數據表的大小有關的。其實這樣做還是全表掃描，只是因為數據量小，只有10萬才快。OK，來個瘋狂的實驗，加到100萬條，測試性能。

加了10倍的數據，馬上t表就到了200多M，而且是定長。還是剛才的查詢語句，時間是0.1-0.2秒完成！分表性能沒問題？錯！因為我們的limit還是9萬，所以快。給個大的，90萬開始

select id from t where vtype=1 order by id limit 900000,10; 看看結果，時間是1-2秒！

why 　 分表了時間還是這么長，非常之郁悶！有人說定長會提高limit的性能，開始我也以為，因為一條記錄的長度是固定的，mysql 應該可以算出90萬的位置才對啊？ 可是我們高估了mysql 的智能，他不是商務數據庫，事實證明定長和非定長對limit影響不大？怪不得有人說 discuz到了100萬條記錄就會很慢，我相信這是真的，這個和數據庫設計有關！

難道MySQL 無法突破100萬的限制嗎？？？到了100萬的分頁就真的到了極限？？？

答案是： NO !!!! 為什么突破不了100萬是因為不會設計mysql造成的。下面介紹非分表法，來個瘋狂的測試！一張表搞定100萬記錄，并且10G 數據庫，如何快速分頁！

好了，我們的測試又回到 collect表，開始測試結論是： 30萬數據，用分表法可行，超過30萬他的速度會慢道你無法忍受！當然如果用分表+我這種方法，那是絕對完美的。但是用了我這種方法后，不用分表也可以完美解決！

答案就是：復合索引！有一次設計mysql索引的時候，無意中發現索引名字可以任取，可以選擇幾個字段進來，這有什么用呢？開始的select id from collect order by id limit 90000,10; 這么快就是因為走了索引，可是如果加了where 就不走索引了。抱著試試看的想法加了 search(vtype,id) 這樣的索引。然后測試

select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！

再測試: select id ,title from collect where vtype=1 limit 90000,10; 非常遺憾，8-9秒，沒走search索引！

再測試：search(id,vtype)，還是select id 這個語句，也非常遺憾，0.5秒。

綜上：如果對于有where 條件，又想走索引用limit的，必須設計一個索引，將where 放第一位，limit用到的主鍵放第2位，而且只能select 主鍵！

完美解決了分頁問題了。可以快速返回id就有希望優化limit ， 按這樣的邏輯，百萬級的limit 應該在0.0x秒就可以分完。看來mysql 語句的優化和索引時非常重要的！

好了，回到原題，如何將上面的研究成功快速應用于開發呢？如果用復合查詢，我的輕量級框架就沒的用了。分頁字符串還得自己寫，那多麻煩？這里再看一個例子，思路就出來了：

select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！

mygod ，mysql 的索引竟然對于in語句同樣有效！看來網上說in無法用索引是錯誤的！

有了這個結論，就可以很簡單的應用于輕量級框架了：

代碼如下：

$db=dblink();

$db-pagesize=20;

$sql="select id from collect where vtype=$vtype";

$db-execute($sql);

$strpage=$db-strpage(); //將分頁字符串保存在臨時變量，方便輸出

while($rs=$db-fetch_array()){

$strid.=$rs['id'].',';

}

$strid=substr($strid,0,strlen($strid)-1); //構造出id字符串

$db-pagesize=0; //很關鍵，在不注銷類的情況下，將分頁清空，這樣只需要用一次數據庫連接，不需要再開；

$db-execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");

php while($rs=$db-fetch_array()):

tr

td$amp;amp;$amp;nbsp; php echo $rs['id']; $amp;amp;$lt;/td

td$amp;amp;$amp;nbsp; php echo $rs['url']; $amp;amp;$lt;/td

td$amp;amp;$amp;nbsp; php echo $rs['sTime']; $amp;amp;$lt;/td

td$amp;amp;$amp;nbsp; php echo $rs['gTime']; $amp;amp;$lt;/td

td$amp;amp;$amp;nbsp; php echo $rs['vtype']; $amp;amp;$lt;/td

td$amp;amp;$amp;nbsp;a act=showid= php echo $rs['id']; $amp;quot;$ target="_blank"$amp;amp;$lt; php echo $rs['title']; $amp;amp;$lt;/a$amp;amp;$lt;/td

td$amp;amp;$amp;nbsp; php echo $rs['tag']; $amp;amp;$lt;/td

/tr

php endwhile;

/table

php

echo $strpage;

通過簡單的變換，其實思路很簡單：1）通過優化索引，找出id，并拼成 "123,90000,12000" 這樣的字符串。2）第2次查詢找出結果。

小小的索引+一點點的改動就使mysql 可以支持百萬甚至千萬級的高效分頁！

通過這里的例子，我反思了一點：對于大型系統，PHP千萬不能用框架，尤其是那種連sql語句都看不到的框架！因為開始對于我的輕量級框架都差點崩潰！只適合小型應用的快速開發，對于ERP,OA，大型網站，數據層包括邏輯層的東西都不能用框架。如果程序員失去了對sql語句的把控，那項目的風險將會成幾何級數增加！尤其是用mysql 的時候，mysql 一定需要專業的dba 才可以發揮他的最佳性能。一個索引所造成的性能差別可能是上千倍！

PS: 經過實際測試，到了100萬的數據，160萬數據，15G表，190M索引，就算走索引，limit都得0.49秒。所以分頁最好別讓別人看到10萬條以后的數據，要不然會很慢！就算用索引。經過這樣的優化，mysql到了百萬級分頁是個極限！但有這樣的成績已經很不錯，如果你是用sqlserver肯定卡死！而 160萬的數據用 id in (str) 很快，基本還是0秒。如果這樣，千萬級的數據，mysql應該也很容易應付。

如果生成千萬級的信息 ，html靜態生成當如何處理？分頁如何處理？

有程序處理和SQL語句處理兩種嘛， 使用 select top 10 name from t_user where name not in(select top 20 name from t_user); --這里只返回十條記錄第3頁的，每頁10條！ 查詢頁數使用count()函數，然后除10，得到頁數 至于程序處理我覺得就是浮云！ 速度自測！

sqlserver數據庫能不能支持千萬級別數據

可以的，我每天都在用

SQLSERVER

查大批量數據，其中千萬的也有，只不過相比ORACLE在性能上會有些低。

請問sqlserver如果要能處理千萬級的數據，機器硬件要求是什么？

sql server 到底能否處理百萬級，千 最近又想起曾經被忽悠過n 次的問題。 剛畢業的時候，很多次去面試的時候被問及sql server 能處理能力， 以及上百萬級別的數據的優化問題？我當然是說東又扯西的，說了一大堆方法 我吹你吹了半天后，得到的提問著告訴我的很輕描淡寫的答案是：不行， sql server 不行，百萬級別還是換oracle 好。 我當時總是很茫然的接受答案。因為我沒玩過，我沒發言權。(但是我搞 的緣由？是到今日，自己面試別人了，也還是不明白當時那些面試官的心態。) 。。。。。。兩年時間過去了。。。。。。 我很有幸在一個小門戶（其實也還好，不是那么小了），玩過百萬級的數 據了。真是很榮幸還能玩到bbs 庫這樣的實時操作比較多的庫。 當我再一次在面試中被問到sql server 的處理能力的時候，我能很有底 氣的告訴他們sql server 能承受百萬級別的處理能力，我也實踐證明了它能。 這時候面試官總是表現得思維很敏捷，問題又很快出來了，處理千萬級別的數 做。 我再次追問面試官給出的答案當然還是無情的否認了sql server。 。。。。。又兩年時間過去了。。。。。。 目前又有幸玩門戶的bbs，記錄是過億的。每天這過億記錄的表的查詢次 數過了千萬，我當然現在沒有去面試，但是我還是真心的在這里希望不要碰到 問我sql server 處理百億級，千億級的數據的性能問題，更不希望告訴我答案 是換oracle。 sql server 我真為它難過。在這里我要為sql server 平反也想在此也問問各 位，目前用sql server 處理數據的級別和對它的看法，當然也可以評論下其他 人對sql server 的看法。

請問sqlserver mysql oracle各有什么優缺點？它們一張表最多能容納多少條記錄？速度誰最快？價格如何呢？

sqlserver 使用簡單，界面友好， 而且單從數據處理速度上看，Sqlserver最快，要高于Mysql 和 oracle 的，

個人做過測試， 千萬級的表，在不做索引的情況下， sqlserver2005 檢查起來不會很費力，

一般的查檢，包括嵌套，搜索時間基本能控制在1分鐘內， 而Mysql基本就跑不動， 在建索引的情況下，也不如sqlserver速度快。 而Oracle 似乎也不是很理想，速度也不如Sqlserver， 也許

億級以上的數據量會比較穩定，但千萬級時沒有sqlserver 快。

缺點：不開源，不跨平臺

Mysql 好處是開源免費，有能力的話可以自己開發與拓民， 這也是現在為什么那么多大企業都用Mysql 的原因之一。

缺點：慢慢慢。

Oracle 的好處大家都知道了， 大型專業數據庫平臺，很多第三方的支持。