那么，MySQL的數(shù)據(jù)量到底能支持多少呢?其實MySQL單表的上限，主要與操作系統(tǒng)支持的最大文件大小有關(guān)。我們來看一下官方的介紹。
1.4.4. MySQL表最大能達到多少
MySQL 3.22限制的表大小為4GB。由于在MySQL 3.23中使用了MyISAM存儲引擎，最大表尺寸增加到了65536TB(2567 – 1字節(jié))。由于允許的表尺寸更大，MySQL數(shù)據(jù)庫的最大有效表尺寸通常是由操作系統(tǒng)對文件大小的限制決定的，而不是由MySQL內(nèi)部限制決定的。
InnoDB存儲引擎將InnoDB表保存在一個表空間內(nèi)，該表空間可由數(shù)個文件創(chuàng)建。這樣，表的大小就能超過單獨文件的最大容量。表空間可包括原始磁盤分區(qū)，從而使得很大的表成為可能。表空間的最大容量為64TB。
在下面的表格中，列出了一些關(guān)于操作系統(tǒng)文件大小限制的示例。這僅是初步指南，并不是最終的。要想了解最新信息，請參閱關(guān)于操作系統(tǒng)的文檔。
MySQL表最大能達到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事實上MySQL能承受的數(shù)據(jù)量的多少主要和數(shù)據(jù)表的結(jié)構(gòu)有關(guān)，并不是一個固定的數(shù)值。表的結(jié)構(gòu)簡單，則能承受的數(shù)據(jù)量相對比結(jié)構(gòu)復雜時大些。
據(jù)D.V.B團隊以及Cmshelp團隊做CMS系統(tǒng)評測時的結(jié)果看來，MySQL單表一般在2千萬條記錄(4G)下能夠良好運行，經(jīng)過數(shù)據(jù)庫的優(yōu)化后5千萬條記錄(10G)下運行良好。那么為什么國內(nèi)的某些CMS廠商還會把其產(chǎn)品自身負載差的責任推給MySQL呢?
這對于MySQL是不公平的，那些CMS廠商非但沒有把內(nèi)核做好反而還在添加很多花哨的功能，最終導致其產(chǎn)品自身負載過低。他們并沒有針對自身負載效果作出相應的數(shù)據(jù)庫優(yōu)化方案及標準，而是繼續(xù)保留著復雜的結(jié)構(gòu)造成對MySQL的資源無休止的浪費，最終導致了其負載上的缺陷，于是他們便充分發(fā)揮中國人的傳統(tǒng)優(yōu)勢——變通：避重就輕的采用了所謂的分表式存儲，雖然在一定程度上緩解了自身負載的缺陷，但是導致了網(wǎng)站后期維護以及資源上的浪費，這樣做是否是長久之計呢?雖然他們解決了眼前的問題，但以后呢?難道想無休止的分表來達到目的?MYLB.NET.CN博主追峰用一個不恰當?shù)谋扔鱽硇稳?，MySQL中的的表就像一塊地，單表就相當于利用這塊地蓋高層建筑充分利用達到高人員負載，但分表就相當于用這塊地蓋了一間平房，如果為了達到高人員負載的話那就需要另開地皮達到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規(guī)劃的嚴重缺陷。那么對于這樣的CMS系統(tǒng)，有誰敢用?難道為了達到讓其良好的運行而無休止的更換著服務器配置么?況且大多情況下一臺服務器中不是只有這么一個網(wǎng)站，那么我們就要思考，我們的腰包是否是為了滿足這么龐大的小CMS而生。
對于某些CMS廠商，MYLB.NET.CN博主追峰只能說其把負載問題推到MySQL身上的做法是極其不負責任的行為，分表的做法是避重就輕毫無責任感的做法，這不僅是對自己的不負責，更是對其用戶的不負責行為，難道你想用把責任推給MySQL以及分表的做法來掩飾自己產(chǎn)品的不足么?大錯特錯，你的這種做法只能愚弄那些剛接觸網(wǎng)站系統(tǒng)對于源碼以及數(shù)據(jù)庫不大了解的初級站長，但是對于大多圈內(nèi)人士你是無法欺騙的;建議這類廠商還是把到各群和網(wǎng)站挑撥是非、夸大宣傳、詆毀他人的時間多多利用到如何改善自己產(chǎn)品讓用戶更好的獲益上;因為不管多初級的站長也會有成為老站長對源碼和數(shù)據(jù)庫駕輕就熟的時候，到那時看清你們本質(zhì)的人會更多。
如此毫無責任感可言的CMS廠商會有多少用戶會忠實于你呢?對自己的產(chǎn)品都沒有責任感，那么對待用戶還剩下多少呢?還有誰敢去選擇你們的產(chǎn)品呢?
這樣不思進取，說一套做一套了，吹噓自己的行為只能是把自己生生地捧得很高，但是別忘了，你的高度是自己吹上去的，用戶才是真正的評論者，到時候你們會摔到什么程度那就要自己思考了。感謝大家對MYLB.NET.CN的支持。
