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