MySQL是中小型網站普遍使用的數據庫之一，然而，很多人並不清楚MySQL到底能支持多大的數據量，再加上某些國內CMS廠商把數據承載量的責任推給它，導致很多不了解MySQL的站長對它產生了很多誤解，那么，MySQL的數據量到底能支持多少呢？其實MySQL單表的上限，主要與操作系統支持的最大文件大小有關。我們來看一下官方的介紹
MySQL表最大能達到多少？ MySQL 3.22 限制的表大小為4GB。由於在MySQL 3.23 中使用了MyISAM 存儲引擎，最大表尺寸增加到了65536TB（2567 – 1字節）。由於允許的表尺寸更大，MySQL數據庫的最大有效表尺寸通常是由操作系統對文件大小的限制決定的，而不是由MySQL內部限制決定的。 InnoDB 存儲引擎將InnoDB 表保存在一個表空間內，該表空間可由數個文件創建。這樣，表的大小就能超過單獨文件的最大容量。表空間可包括原始磁盤分區，從而使得很大的表成為可能。表空間的最大容量為64TB。
事實上MySQL 能承受的數據量的多少主要和數據表的結構有關，並不是一個固定的數值。表的結構簡單，則能承受的數據量相對比結構復雜時大些。
據D.V.B 團隊以及Cmshelp 團隊做CMS 系統評測時的結果來看，MySQL單表大約在2千萬條記錄（4G）下能夠良好運行，經過數據庫的優化后5千萬條記錄（10G）下運行良好。那么為什么國內的某些CMS廠商還會把其產品自身負載差的責任推給MySQL呢？
這對於MySQL是不公平的，那些CMS廠商非但沒有把內核做好反而還在添加很多花哨的功能，最終導致其產品自身負載過低。他們並沒有針對自身負載效果作出相應的數據庫優化方案及標准，而是繼續保留着復雜的結構造成對MySQL的資源無休止的浪費，最終導致了其負載上的缺陷，於是他們便充分發揮中國人的傳統優勢——變通：避重就輕的采用了所謂的分表式存儲，雖然在一定程度上緩解了自身負載的缺陷，但是導致了網站后期維護以及資源上的浪費，這樣做是否是長久之計呢？雖然他們解決了眼前的問題，但以后呢？難道想無休止的分表來達到目的？
用一個不恰當的比喻來形容，MySQL中的的表就像一塊地，單表就相當於利用這塊地蓋高層建築充分利用達到高人員負載，但分表就相當於用這塊地蓋了一間平房，如果為了達到高人員負載的話那就需要另開地皮達到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規划的嚴重缺陷。
那么對於這樣的CMS系統，有誰敢用？難道為了達到讓其良好的運行而無休止的更換着服務器配置么？況且大多情況下一台服務器中不是只有這么一個網站，那么我們就要思考，我們是否是為了滿足這么龐大的小CMS 而掏腰包。
建議某些CMS 廠商改善自己的產品，讓用戶更好的獲益。否則，還有誰敢去選擇你們的產品呢？