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到底能支援多大的資料量？
mysql是中小型 普遍使用的資料庫之一，然而，很多人並不清楚mysql到底能支援多大的資料量，再加上某些國內cms廠商把資料承載量的責任推給它，導致很多不了解mysql的站長對它產生了很多誤解，那麼，mysql的資料量到底能支援多少呢？其實mysql單錶的上限，主要與作業系統支援的最大檔案大小有關...
MySQL到底能支援多大的資料量？
mysql表最大能達到多少？mysql 3.22 限制的表大小為4gb。由於在mysql 3.23 中使用了myisam 儲存引擎，最大表尺寸增加到了65536tb 2567 1位元組 由於允許的表尺寸更大，mysql資料庫的最大有效表尺寸通常是由作業系統對檔案大小的限制決定的，而不是由mysql內...
這個產品能支援多大資料量？
經常有使用者會問這個問題，你家的產品能處理多大資料量？似乎是這個值越大產品就越牛。這個問題，其實沒多大意義。能處理多大的資料量，還有個很關鍵的因素是期望的響應時間，在脫離這個因素單純談大資料產品的資料處理量，就不知道怎麼回答了。考慮只有單台機器的簡單情況。如果是希望秒級響應的olap式彙總，那麼gb...