MySQL到底能支援多大的資料量？

標籤：

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 廠商改善自己的產品，讓使用者更好的獲益。否則，還有誰敢去選擇你們的產品呢？

MySQL到底能支援多大的資料量？